炸死了你，我的故事就该完了。炸死了我，你的故事还长着呢！。

高性能可扩展MySQL数据库设计及架构优化 电商项目（笔记）

##数据库开发规范的制定 　　数据库必须使用小写字母并用下划线分割（见名知意，最好不超过32字符）

　　禁止使用的MySQL保留关键字（如有，``包裹），去http://dev.mysql.com/doc/refman/5.7/en/keywords.html

　　临时库表必须以TMP为前缀并以日期为后缀（tmp_）

　　备份库和库，必须以BAK为前缀，日期为后缀（bak_）

　　所有存储相同数据的列名和列类型必须一致。（在多个表中的字段如USER_ID）

　　mysql5.5之前默认的存储的引擎是的myisam，没有特殊要求，所有的表必须使用innodb的（支持失误，行级锁，高并发下性能更好）

　　数据库和表的字符集统一使用UTF8【要统一，避免由于字符集转换产生的乱码】。汉字UTF8下暂3个字节

　　表和字段备注

　　尽量控制单表数据量的大小在500万以内（并不是的MySQL数据库的限制，这种限制取决于存储设置和文件系统，可以使用历史数据归档，分库分表来实现）。

###注意：

　　谨慎使用MySQL的分区表（分区表在物理上表现为多个文件，在逻辑上表现为一个表）。

　　谨慎选择分区键，跨分区查询效率可能更低

　　建议使用物理分表的方式管理大数据

　　尽量做到冷热数据分离，减小表的宽度（MySQL的限制最多存储4096列，行数没有限制，但是每一行的字节总数不能超过65535）【列限制好处：减少磁盘IO，避免读入无用的冷数据】

　　禁止在表中建立预留字段（无法确认存储的数据类型，无法选择合适的类型）

　　禁止在数据中存储图片，文件二进制数据

　　禁止在线上做数据库压力测试

　　禁止从开发环境，测试环境直接连生产环境数据库

##索引设计规范 　　对查询性能非常重要（双刃箭）

　　限制每张表上的索引数量，建议单表索引不超过5个（索引会增加查询效率，但是会降低插入和更新的速度）

　　禁止给表中的每一列都建立单独的索引

　　每个innodb的表必须有一个主键（不能使用更新频繁的列作为主键），选择自增ID

##常见索引建立建议：

　　　　select，update，delete语句的where从句的列

　　　　包含order by，group by，distinct中的字段

　　　　多表连接的关联列

　　如何选择索引列的顺序：

　　　　区分度最高的列放在联合索引的最左侧

　　　　尽量把字段长度小的列放在联合索引的最左侧

##注意：

　　避免建立冗余索引和重复索引

　　尽量避免使用外键

##数据库字段设计规范 　　优先选择符合存储需要的最小数据类型

　　优先使用无符号的整形来存储

　　优先选择存储最小的数据类型（VARCHAR（N），N代表的是字符数，而不是字节数，N代表能存储多少个汉字）

　　避免使用的文字，BLOB类型

　　尽量把所有的列定义为not null（索引null需要额外的空间来保存，所以需要暂用更多的内存）

　　使用时间戳或日期时间类型来存储时间

　　同财务相关的金额数据，采用十进制类型（不丢失精度）

　　建议使用预编译语句进行数据库操作

　　禁止跨库查询

　　禁止选择*查询，消耗更多的cpu和io及网络带宽资源。

　　避免使用子查询(当一个查询是另一个查询的条件时，称之为子查询)，可以把子查询优化为 join 操作

例如：select * from table_name1 where condition_column in(select condition_column from table_name2)第二个查询就是子查询

##mysql的分区表 　　确认mysql服务器是否支持分区表：show plugins;
　　在逻辑上为一个表，在物理上存储在多个文件中。
分区表 可以提高性能 详情
主从复制（读写分离）
在业务复杂的系统中，有这么一个情景，有一句sql语句需要锁表，导致暂时不能使用读的服务，那么就很影响运行中的业务，使用主从复制，让主库负责写，从库负责读，这样，即使主库出现了锁表的情景，通过读从库也可以保证业务的正常运作。
详情
详情

转：https://blog.csdn.net/ljk168/article/details/82916677

## Myabtis 一对多分页问题 今天在用 Myabtis 进行一对多分页的时候，无论怎么分页都总是少好几条。 不知道你们有没有遇到。
原因：把 limit 放在了是最后面，导致 MyBatis 是按照从记录进行分页的 也就是结果不对。
解决方法：将 Limit 分页条件放置在主记录后，也就是先按照主记录分页，再连表查询，完美解决。条件问题