1 MySQL的继续执行业务流程
为的是更快的去强化SQL，这儿先归纳了呵呵SQL继续执行业务流程：
1、应用程序允诺到服务器端，服务器端透过资料库相连池，用JDBC相连资料库驱动力。 2、资料库端相连池转交到服务器端相连，接着把服务器端对资料库的允诺交予资料库的缓存。 3 4、接着是透过资料库导出器对SQL展开导出（导出成资料库重新认识的词汇）。 5、接着透过SQL查阅强化器赢得最优化继续执行SQL。 6、最后把最优化SQL交予资料库开伞器。 7、开伞器优先选择现阶段资料库的储存发动机（示意图选用InnoDB为例）。 8、接着先去资料库的BufferPool（内存）中查阅，这儿假如投弹了内存则间接回到结果。 9、假如没在内存中投弹结论，所以会去硬碟中抹除，接着回到结论集并内存出来，以期到时候收纳。SQL继续执行业务时序：
2 资料库选用规范化
科学合理选用资料库规范化也是SQL操控性强化的大前提。
1、表重新命名要大写字母且换行拆分单词； 2、表中文名称及Hamming称千万别用资料库的URL； 3、资料库表重新命名不超过32个字符； 4、遵循资料库三范式； 5、科学合理的反三范式选用（比如科学合理的冗余字段再一张表）；3 45个SQL强化计划
涉及到钱的字段用decimal非精准浮点：float,double。 精准浮点：decimal。 Decimal： 1、底层储存的数据转成字符串形式储存，因此能保持精度； 2、可存比bigint更大的数据； 3、在计算时不会丢失精度； 4、占用空间由定义的宽度决定，每4个字节可以储存9位数字，并且小数点要占用一个字节；尽量不用ENUM类型1、禁止把数字作为ENUM值； 2、修改ENUM值需用ALTER语句； 3、ENUM类型选用ORDER BY效率极低；避免distinct过滤字段过多1、distinct选用时CPU占用时间长 2、对重复数据比较、过滤的过程会占用系统资源，如cpu时间。 3、查阅回到字段多时，用distinct资料库会对重复数据展开过滤。where后默认值替换null1、假如默认值替换null，往往可以解决这个问题。 2、资料库优化器发现，走索引比不走索引成本还要高，就会放弃索引，这些条件 !=，<>，is null，is not null经常被认为让索引失效，这些都是强化器自动放弃索引的；where后避免选用!=、<>1、!=、<>可能会让索引失效。 2、在where后用!=、<>，发动机可能会不用索引而全表扫描。相连表，优先用inner joininner join 、left join和right join三种相连表：
1、inner join 内相连，只保留两张表中完全匹配的结论集； 2、left join 会回到左表所有的行，即使在右表中没匹配的记录； 3、right join会回到右表所有的行，即使在左表中没匹配的记录；1、用left join左表数据结论尽量小，条件尽量放到左边处理； 2、假如回到结论相同，优选inner join； 3、假如inner join是等值相连，回到的行数比较少，操控性相对会好一点；操控性最优化原则：小表驱动力大表，小的数据集驱动力大的数据集；
表必用Innodb储存发动机所有表尽量用Innodb储存发动机。
1、Innodb 支持事务，支持行级锁，更快的恢复性，高并发下操控性更快。 2、当Innodb无法满足的功能（如列储存，储存空间数据等）才不选用Innodb。 3、mysql5.5之前默认选用Myisam，5.6以后默认的为Innodb。 Innodb表必有主键Innodb是一种索引组织表：数据的储存的逻辑顺序和索引的顺序是相同的。表可以有多个索引，但是储存顺序只可一种，也就是主键只能有一个。
Innodb是按照主键索引的顺序来组织表的： 1、主键最好用自增数字ID，效率最高； 2、更新频繁的的列不适合作为主键； 3、假如用UUID、MD5、HASH、字符串列作为主键，则无法保证数据的顺序增长；资料库和表的字符集统一资料库和表的字符集统一选用UTF8。
1、兼容性更快。 2、不同的字符集展开比较前需要展开转换，这样会造成索引失效。 3、假如储存emoji表情的，要选用utf8mb4字符集。 4、可避免字符集转换产生的乱码。避免选用select *查阅语句要制定具体的字段，千万别查阅所有。
select *弊端： 1、增加了回表的可能性； 2、查阅效率低； 3、增加不必要的消耗，比如CPU、IO、内存、网络带宽； 4、增加了选用覆盖索引的可能性； group by语句效率强化先过滤，后分组，这样可以在继续执行到该语句前，把不需要的记录过滤掉。
正确选用示例：
select a，avg（b） from user where a =1 or b = 2 group by a;禁用：group by 字段 having 条件;
用truncate清空表1、truncate table不能用于参与了索引视图的表。 2、truncate table比 delete快，且用到的系统和事务日志资源少。 3、delete一行数据都要在事务日志中记录一行。truncate table透过释放储存表数据所用的数据页来删除数据，并且只在事务日志中记录页的释放。 delete、update语句，加个limit或者循环分批次删除1、降低写错SQL清空表数据的风险。 2、SQL效率很可能更高SQL中加了limit 1，假如第一条就投弹目标return， 没limit的话，还会继续继续执行扫描表。 3、避免长事务delete继续执行时,假如age加了索引，MySQL会将所有相关的行加写锁和间隙锁，所有继续执行相关行会被锁住，假如删除数量大，会间接影响相关业务无法选用。（4）数据量大的话，容易把CPU打满假如你删除数据量很大时，不加limit限制呵呵记录数，容易把cpu打满，导致越删越慢。（5）锁表一次性删除太多数据，可能造成锁表，会有lockwait timeout exceed的错误，所以建议分批操作。UNION ALL操作符替代UNION1、UNION ALL替代UNION，前者只是简单的将两个结论合并后就回到。 2、UNION相连表后会结论集排序接着去掉重复数据，在回到结论。IN选用的字段千万别过多MySQL的IN中的常量全部储存在一个数组中，这个数组是排序的。假如值过多，产生的消耗也是比较大的。假如是连续的数字，可以选用between代替，或者选用相连查阅替换。
批量插入代替普通插入批量处理是一次事务开启和提交，而每次单条插入都会提交一次事务。
选用示例：
INSERT INTO product (id,name) VALUES(1,123123),(2,123123);索引列上不用内置函数索引列上选用内置函数，会导致索引失效。
复合索引选用时排序强化排序时应按照复合索引中各列的顺序展开排序，否则排序操控性会比较差。
复合索引最左特性复合索引不满足最左原则，索引一般会失效。
当创建一个复合索引的时，如创建(k1,k2,k3)，相当于创建了（k1）、(k1,k2)和(k1,k2,k3)三个索引，这就是最左匹配原则。选用案例：
1、复合索引全选用，按左侧顺序选用，索引生效 SELECT * FROM test WHERE name=12321 AND salary=1000 2、如下虽违背了最左特性，但资料库继续执行时会展开强化，也会选用到索引，自动给颠覆过来SELECT * FROM test WHERE salary=1000 AND NAME=12321 3、满足复合索引的最左特性 SELECT * FROM test WHERE name=12312 4、创建复合索引 ALTER TABLE test ADD INDEX idx_name_salary (name,salary) 5、没出现左边的字段，则不满足最左特性，复合索引会失效SELECT * FROM test WHERE salary=1000必要用force index强制选用索引根据自己业务需求，有时候可以用forceindex来强制强化器选用创建的索引。
like语句优化模糊查阅的一些场景，可能让索引失效，因此选用时需要注意。
1、尽量不用避免模糊查阅； 2、全模糊查阅是无法强化的，一定要选用的话建议选用搜索发动机。 3、假如要用like，应尽量选用右模糊查阅， 即like ‘…%’，是会选用索引的； 4、左模糊like ‘%…’无法间接选用索引，但可以利用reverse + function index的形式，变化成 like ‘…%’；避免产生大事务操作大批量操作数据时，假如在一个事务中，会造成表中大批量数据展开锁定，从而导致大量的阻塞，对资料库操控性影响很大。
尽量把查阅语句剥离事务逻辑。
用预编译语句操作资料库1、能解决动态SQL所带来的SQL注入的问题； 2、预编译语句可以重复选用这些计划，减少SQL编译所需要的时间； 3、只传参数，比传递SQL语句更高效。相同语句可以一次导出，多次选用，提高处理效率。频繁的查阅优先考虑选用覆盖索引覆盖索引：就是包含了所有查阅字段(where,select,ordery by,group by包含的字段)的索引。
覆盖索引的好处： 1、避免Innodb表展开索引的二次查阅 2、可以把随机IO变成顺序IO加快查阅效率科学合理优先选择索引列的顺序1、选用最频繁的列放到联合索引的左侧。 2、区分度最高的放在联合索引的最左侧（区分度=列中不同值的数量/列的总行数）。 3、尽量把字段长度小的列放在联合索引的最左侧（字段长度越小，一页能储存的数据量越大，IO操控性也就越好）。 禁止表中建立过多索引MYSQL每张表最多建16个索引。并不是索引越多越好，要科学合理的建索引，因为所有创建本身也需要时间和储存。
索引不宜太多，一般5个以内。
1、一个表的索引数最好千万别超过5个，若太多需要考虑一些索引是否有存在的必要； 2、索引可以理解为一个就是一张表，其可以储存数据，其数据就要占空间； 3、索引并不是越多越好，虽其提高了查阅的效率，但却会降低插入和更新的效率； 4、索引表的数据是排序的，排序也是要花时间的； 5、insert或update时有可能会重建索引，假如数据量巨大，重建将展开记录的重新排序，所以建索引需要慎重考虑，视具体情况来定；连表查阅连表避免过多表相连不宜太多，一般5个以内。
1、应该把相连表拆开成较小的几个继续执行，可读性更高 2、假如一定需要相连很多表才能得到数据，所以意味着这是个糟糕的设计了 3、阿里规范化中，建议多表联查三张表以下 4、关联的表个数越多，编译的时间和开销也就越大 5、每次关联内存中都生成一个临时统一SQL语句的写法select * from a; select * From A;上面的两条sql语句，平常我们看来是一样的，实际资料库强化器认为他们是不一样的，这样数据库导出器就会导出两次，生成两个不同的继续执行计划。
因此相同的sql语句要统一写法，这样可以减少资料库导出次数，避免生产两个不同继续执行计划。
SQL要尽量简单化SQL继续执行计划是可以被重用的，SQL越简单，被重用的概率越大，生成继续执行计划也是很耗时的。
嵌套子查阅、3张表以内关联查阅平常很常见。假如超过3层嵌套查阅，查阅强化器很容易给出错误的继续执行计划，影响SQL效率。临时表注意事项1、假如数据量不大，为的是缓和系统表的资源，应先create table，接着insert； 2、假如选用到了临时表，在储存过程的最后务必将所有的临时表显式删除。先 truncate table ，接着 drop table，这样可以避免系统表的较长时间锁定。3、避免频繁创建和删除临时表，以减少系统表资源的消耗； 4、在新建临时表时，假如一次性插入数据量很大，所以可以选用 select into 代替 create table，避免造成大量 log； 大SQL查阅拆多个小查阅通常为的是达到更快的操控性以及更快的数据控制，可以把大SQL查阅拆多个小查阅。
explain分析SQL继续执行计划type： 1、all：全表扫描； 2、system：表仅有一行，基本用不到； 3、eq_ref：对于每个来自于前面的表的行组合，从该表中读取一行。这可能是最好的相连类型，除了const类型； 4、ref：对于每个来自于前面的表的行组合，所有有匹配索引值的行将从这张表中读取； 5、const：表最多一行数据配合，主键查阅时触发较多； 6、操控性排名：system > const > eq_ref > ref > range > index > all。 7、实际sql强化中，最后达到ref或range级别。 8、range：只检索给定范围的行，选用一个索引来优先选择行。当选用=、<>、>、>=、<、<=、IS NULL、<=>、BETWEEN或者IN操作符，用常量比较URL列时，可以选用range； 9、index：该联接类型与ALL相同，除了只有索引树被扫描。这通常比ALL快，因为索引文件通常比数据文件小； Extra常用URL： 1、Using 2、Using temporary：mysql常建一个临时表来容纳结论，典型情况如查阅包含可以按不同情况列出列的GROUP BY 3、和ORDER BY子句时； 4、Using where：WHERE子句用于限制哪一个行匹配下一个表或发送到客户。除非你专门从表中索取或检查所有行，假如Extra值不为Using where并且表联接类型为ALL或index，查阅可能会有一些错误。需要回表查阅。 读写分离与分库分表当数据量达到一定的数量之后，通常用读写分离、分库、分表层面来强化了。
1、分表适用于中等数据量； 2、分库与分表一般是结合着用，适用于大数据量的储存了，这也是现在大型互联网公司解决数据储存的方法之一。 3、读写分离适用于较小一些的数据量；深分页强化深分页强化计划：标签记录法、延迟关联法。
选用示例：
1、标签记录法： SELECT id, quarantine_num, quar_product_num FROMquarantine_detailWHERE id > 100000 LIMIT 10; 2、延迟关联法： SELECT qd2.id, qd2.quarantine_num, qd2.quar_product_num FROM quarantine_detail qd2 INNER JOIN ( SELECT qd1.id FROM quarantine_detail qd1 WHERE qd1.quarantine_num > 1 LIMIT 120000, 10 ) AS a ON a.id = qd2.id;MYSQL单表数据量控制在500w以内MySQL通常我们控制数据量小于500w，过大会造成修改表结构，备份，恢复都会有很大的问题。
1、日志数据： 可以用历史数据归档。 2、业务数据： 分库分表等控制数据量大小。TEXT或BLOB类型只能选用前缀索引MySQL中索引字段长度是有限制的，因此TEXT或BLOB类型只能选用前缀索引。
把BLOB或TEXT列剥离到扩展表中Mysql内存临时表不支持TEXT、BLOB类型，因此此类型数据在查阅中，就不能用内存临时表，要用磁盘临时表展开。而且资料库还要展开二次查阅，sql操控性就显得很差。所以最好把把BLOB或TEXT列剥离到单独的扩展表中储存。
禁止在资料库中储存图片，文件等大的二进制数据通常文件很大，会短时间内造成数据量快速增长，资料库展开资料库读取时，通常会展开大量的随机IO操作，文件很大时，IO操作很耗时。通常储存文件到文件储存服务器或者MongoDB等。
表尽量千万别建预留字段1、对预留字段类型的修改，会对表展开锁定； 2、预留字段的重新命名很难做到见名识义； 3、预留字段无法确认储存的数据类型，所以无法优先选择合适的类型；尽量做到冷热数据分离，减小表的宽度Mysql限制每个表最多储存4096列，并且每一行数据的大小不能超过65535字节.
1、经常一起选用的列放到一个表中（避免更多的关联操作）。 2、更有效的利用内存，避免读入无用的冷数据； 3、减少磁盘IO,保证热数据的内存内存投弹率（表越宽，把表装载进内存缓冲池时所占用的内存也就越大,也会消耗更多的IO）；谨慎用Mysql分区表1、谨慎优先选择分区键，跨分区查阅效率可能更低； 2、建议选用物理分表的方式管理大数据。 3、分区表在物理上表现为多个文件，在逻辑上表现为一个表；常见其它强化1、SQL书写格式，URL大小保持一致，选用缩进。 2、很多时候用 exists 代替 in 是一个好的优先选择 3、where后面的字段，留意其数据类型的隐式转换。 4、修改或删除重要数据前，要先备份。 5、假如排序字段没用到索引，就尽量少排序 6、当只需要一条数据的时候，选用limit 1limit 1 可以避免全表扫描，找到对应结论就不会再继续扫描了。 7、所有表和字段都需要添加注释选用comment从句添加表和列的备注，从一开始就展开数据字典的维护。 8、伪删除设计 9、尽量避免选用游标因为游标的效率较差，假如游标操作的数据超过1万行，所以就应该考虑改写。 10、尽量把所有列定义为NOT NULL NOT NULL列更节省空间，NULL列需要一个额外字节作为判断是否为 NULL的标志位。NULL 列需要注意空指针问题，NULL列在计算和比较的时候，需要注意空指针问题。 11、索引不适合建在有大量重复数据的字段上，比如性别，排序字段应创建索引
