你好，我是被白菜拱的猪。
爱学习、爱睡觉、迷恋女孩的性感恬静的编码手册。
你知道文章目录SQL调整吗？ 查询缓存Explain覆盖索引唯一索引常规索引前缀索引条件字段函数操作总结SQL优化知道吗？ 查询缓存
如果数据库小于或等于8.0，请检查缓存是否打开，如果是非静态表，请选择关闭缓存。
由于禁用查询缓存非常频繁，因此只要有对表的更新，此表中的所有查询缓存都将为空。 因此，你辛苦地保存结果，还没有使用，一个更新可能就全部空了。 对于更新压力较大的数据库，查询缓存命中率非常低。 除非你的业务有静态时钟，否则很长时间都不会更新。 例如，在系统清单中，此表中的查询适合使用查询缓存。
MySQL 8.0删除了查询缓存的这一部分。
Explain解决了查询缓存问题后，它使用Explain分析SQL语句，以分析执行了哪些索引、读取表的顺序以及优化程序查询了每个表中的多少行。
explain包含哪些字段？
id :选择查询的序列号。 id值越大，优先顺序越高，先执行。 select_type:查询的类型确定查询是什么类型，以区分常规查询、联合查询、子查询等。 SIMPLE、PRIMARY和SUBQUERYtable :显示此行中的数据是针对哪个表的。 类型：显示查询中使用的system、const、eq_ref、ref、range、index和all possible_keys:类型。 表示至少有一个索引可能应用于此表。 如果与查询相关的字段中有索引，则会列出该索引，但不一定会被查询实际使用。 key :实际使用的索引为NULL时不使用索引。 如果使用覆盖索引，则该索引将显示在key列表的key_len:索引中使用的字节数。 使用的索引长度越短越好，而不损失精度。 ref )使用文件、使用时间，用于根据表统计信息和索引选择情况估算查询需要读取的行数(Extra )以及其他重要信息(指示索引使用rows的列)
行数是采样统计信息的一种方法，默认情况下选择n个数据页。 即使行数少，索引也可能无法前进。 由于存在返回表的现象，优化程序认为返回表的成本比直接扫描整个表要好。
如果explain rows与实际情况之间的差异很大，请尝试使用analyze table重新统计索引信息。 或者force index强制他索引。
由于覆盖索引如上所述返回到表中，所以在优化SQL方面，我将尽量避免返回到表中。 在那里建立封面索引，在选择时尽量使用封面索引。 覆盖索引可以减少树的搜索次数，显著提高查询性能。
为了更好地使用覆盖索引，我会建立一些联合索引。 这与覆盖索引一样减少返回表的次数。
唯一的索引change buffer减少了随机磁盘访问。 change buffer的主要目的是缓存记录的更改操作。 因此，在单个数据页上创建合并之前，change buffer记录的更改越多，收入就越大。
因此，在泛读少读的业务中，页面写完后立即被访问的概率很低，此时使用change buffer效果最好。 这种业务模式中常见的是账单系统、日志系统。
用于泛读少读的业务。 如果读写较少，则更新到change buffer，但之后立即访问该数据页并立即出发到merge，因此该随机访问IO的次数不会减少，反而change buffer的维护成本不会减少
索引邮箱，将字符串的一部分定义为索引。 使用前缀索引定义长度可以节省空间，而不会增加额外的查询成本。
很长的字段，想做索引我们怎么去优化他呢？
由于存在磁盘使用问题，选择索引越长，磁盘空间就越大，可以放在同一数据页上的索引值就越少，搜索效率就越低。 我们的做法是减少索引的长度。
使用混列将字段混列另存为其他字段，并每次检查混列。 例如，可以通过剪切电子邮件地址www .或身份证区域开头的同一区域中的人很多等划分度较低的字段来反转reverse ()。 按函数计算条件字段函数操作字段时，不会创建索引。
隐式类型转换，where id=1相当于添加了函数隐式字符编码转换，如CAST ()。 这两个表字符集不同(转换过程中转换) )的函数。 索引不可用了，让我们一起看看是否有缓存，然后提前展开，看看参数是否与预期的不同，以及行数是否正确。 因为是采样，所以不管是看索引还是不看索引，索引都不一定要进行索引。 因为有返回表的消耗，所以如果想强制索引的话，可以使用force index。 如果可能返回表，请查看覆盖索引是否可用，如果要合并索引，请查看是否符合最左前缀原则，如果不符合，请重新排序SQL语句，5.6或更高版本按下索引，合并表
如果要索引字符串，请使用前缀索引指定长度、散列、剪切或闪存来减少字符串长度。 而且，不建议对索引使用函数。 一般来说，如果使用函数，就无法到达索引。 字符集的差异也是如此。