资料库大批应用领域软件开发工程项目中，绝大多数情况下，资料库的操作方式操控性正式成为整座应用领域的操控性困局。
统计数据时），都须要特别注意统计数据操作方式的操控性。责任编辑他们以 MySQL 资料库为例展开探讨。
资料库强化最终目标
增加 IO 单次
IO 总有一天是资料库最难困局的地方性，这是由资料库的职能所下定决心的，绝大部分资料库操作方式中少于90%的天数都是 IO 操作方式所挤占的，增加 IO 单次是 SQL 强化中须要第三优先选择考量，总之，也是效果显著最显著的强化方式。
增加 CPU 排序
除 IO 困局以外，SQL 强化中须要考量的是 CPU 演算量的强化了。
order by、group by、distinct……都是耗用 CPU 的巴韦县（那些操作方式大体上都是 CPU 处置缓存中的统计数据较为演算）。当他们的 IO 强化努力做到很大期后，增加 CPU 排序也就正式成为了他们 SQL 强化的关键最终目标。
MySql查阅操作过程
资料库强化方式
SQL语句强化
明确了强化最终目标后，他们须要确定达到他们最终目标的方式。
对于 SQL 语句来说，达到上述2个强化最终目标的方式其实只有一个，那是改变 SQL 的执行计划，让他尽量“少走弯路”，尽量通过各种“捷径”来找到他们须要的统计数据，以达到“增加 IO 单次”和“增加 CPU 排序”的最终目标。
尽量少 Join
MySQL 的优势在于简单，但这在某些方面其实也是其劣势。MySQL 强化器效率高，但是由于其统计信息的量有限，强化器工作操作过程出现偏差的可能性也就更多。
对于复杂的多表 Join ，一方面由于其强化器受限，再者在 Join 这方面所下的功夫还不够，所以操控性表现离 Oracle 等关系型资料库前辈还是有很大距离。
但如果是简单的单表查阅，这一差距就会极小甚至在有些场景下要优于那些资料库前辈。
尽量少排序
排序操作方式会耗用较多的 CPU 资源，所以增加排序可以在缓存命中率高等 IO 能力足够的场景下会较大影响 SQL的响应天数。
尽量避免 select *
尽量避免 select *，同时尽量用Join代替子查阅。
尽量少使用“or”关键字
当 where 子句中存在多个条件以“或”并存的时候，MySQL 的强化器并没有很好的解决其执行计划强化问题，再加上 MySQL 特有的 SQL 与 Storage 分层架构方式，造成了其操控性比较低下，很多时候使用 union all 或者是union（必要的时候）的方式来代替“or”会得到更好的效果。
尽量用 union all 代替 union
union 和 union all 的差异主要是前者须要将两个（或者多个）结果集合并后再展开唯一性过滤操作方式，这就会涉及到排序，增加大批的 CPU 演算，加大资源耗用及延迟。
所以当他们可以确认不可能出现重复结果集或者不在乎重复结果集的时候，尽量使用 union all 而不是 union。
避免类型转换
避免类型转换，能用DISTINCT的就不用GROUP BY，尽量不要用SELECT INTO语句。
从全局出发强化，而不是片面调整
SQL 强化不能是单独针对某一个展开，而应充分考量系统中所有的 SQL，尤其是在通过调整索引强化 SQL的执行计划的时候，千万不能顾此失彼，因小失大。
表结构强化
MySQL 资料库是基于行（Row）存储的资料库，而资料库操作方式 IO 的时候是以 page（block）的方式，也是说，如果他们每条记录所挤占的空间量减小，就会使每个page中可存放的统计数据行数增大，那么每次 IO 可访问的行数也就增多了。
反过来说，处置相同行数的统计数据，须要访问的 page 就会增加，也是 IO 操作方式单次增加，直接提升操控性。
统计数据类型选择
原则是：统计数据行的长度不要少于8020字节，如果少于这个长度的话在物理页中这条统计数据会挤占两行从而造成存储碎片，增加查阅效率。
字段的长度在最大限度的满足可能的须要的前提下，应该尽可能的设得短一些，这样可以提高查阅的效率，而且在建立索引的时候也可以增加资源的耗用。
数字类型
非万不得已不要使用DOUBLE，不仅仅只是存储长度的问题，同时还会存在精确性的问题。同样，固定精度的小数，也不建议使用DECIMAL，建议乘以固定倍数转换成整数存储，可以大大节省存储空间，且不会带来任何附加维护成本。
字符类型
定长字段，建议使用 CHAR 类型（char查阅快，但是耗存储空间，可用于用户名、密码等长度变化不大的字段），不定长字段尽量使用 VARCHAR（varchar查阅相对慢一些但是节省存储空间，可用于评论等长度变化大的字段）。
且仅仅设定适当的最大长度，而不是非常随意的给一个很大的最大长度限定，因为不同的长度范围，MySQL也会有不一样的存储处置。
天数类型
使用TIMESTAMP类型，因为其存储空间只须要DATETIME 类型的一半。
对于只须要精确到某一天的统计数据类型，建议使用DATE类型，因为他的存储空间只须要3个字节，比TIMESTAMP还少。不建议通过INT类型类存储一个unix timestamp 的值，因为这太不直观，会给维护带来不必要的麻烦，同时还不会带来任何好处。
ENUM &SET
对于状态字段，可以尝试使用 ENUM 来存放，因为可以极大的增加存储空间，而且即使须要增加新的类型，只要增加于末尾，修改结构也不须要重建表统计数据。
字符编码
字符集直接下定决心了统计数据在MySQL中的存储编码方式，由于同样的内容使用不同字符集表示所挤占的空间大小会有较大的差异，所以通过使用合适的字符集，可以帮助他们尽可能增加数据量，进而增加IO操作方式单次。
尽量使用 NOT NULL
NULL 类型较为特殊，SQL 难强化。
虽然 MySQL NULL类型和 Oracle 的NULL有差异，会进入索引中，但如果是一个组合索引，那么这个NULL 类型的字段会极大影响整座索引的效率。
虽然 NULL空间上可能确实有很大节省，倒是带来了很多其他的强化问题，不但没有将IO量省下来，反而加大了SQL的IO量。
所以尽量确保 DEFAULT 值不是 NULL，也是一个很好的表结构设计强化习惯。
资料库架构强化
分布式和集群化
负载均衡
负载均衡集群是由一组相互独立的排序机系统构成，通过常规网络或专用网络展开连接，由路由器衔接在一起，各节点相互协作、共同负载、均衡压力，对客户端来说，整座群集可以视为一台具有超高操控性的独立服务器。
MySQL一般部署的是高可用性负载均衡集群，具备读写分离，一般只对读展开负载均衡。
读写分离
读写分离简单的说是把对资料库读和写的操作方式分开对应不同的资料库服务器，这样能有效地减轻资料库压力，也能减轻 IO 压力。
主资料库提供写操作方式，从资料库提供读操作方式，其实在很多系统中，主要是读的操作方式。当主资料库展开写操作方式时，统计数据要同步到从的资料库，这样才能有效保证资料库完整性。
统计数据切分
通过某种特定的条件，将存放在同一个资料库中的统计数据分散存放到多个资料库上，实现分布存储，通过路由规则路由访问特定的资料库，这样一来每次访问面对的就不是单台服务器了，而是N台服务器，这样就可以增加单台机器的负载压力。
其他强化
适当使用视图加速查阅
把表的一个子集展开排序并创建视图，有时能加速查阅（特别是要被多次执行的查阅）。
它有助于避免多重排序操作方式，而且在其他方面还能简化强化器的工作。视图中的行要比主表中的行少，而且物理顺序是所要求的顺序，增加了磁盘I/O，所以查阅工作量可以得到大幅增加。
算法强化
尽量避免使用游标，因为游标的效率较差，如果游标操作方式的数据少于1万行，那么就应该考量改写。使用基于游标的方式或临时表方式之前，应先寻找基于集的解决方案来解决问题，基于集的方式通常更有效。
与临时表一样，游标并不是不可使用。对小型统计数据集使用 FAST_FORWARD 游标通常要优于其他逐行处置方式，尤其是在必须引用几个表才能获得所需的统计数据时。
封装存储操作过程
经编译和强化后存储在资料库服务器中，运行效率高，可以增加客户机和服务器之间的通信量，有利于集中控制，易于维护。
End
~
往期回顾
这款超好用的自动化测试工具，是我的神！
