MySQL Tips

 

MySQL中的一些Tips，我的总结或者整理自网络

 

不明白为何MySQL的不少材料中老是喜欢把联合（复合）索引和覆盖索引放在一块说事？

1，联合索引是一种索引的类型，指建立索引的时候包含了多个字段。
2，覆盖索引是一种查询优化行为，索引结构自己就能够知足查询，无需回表，而不是一种索引。
3，联合索引和覆盖索引并无任何须然关系，单个字段的索引也有可能会发生覆盖索引的状况。

---

MySQL中的filesort

"using filesort" means that the sort can't be performed with an index. 仅此而已，并不必定真的使用文件完成排序。
mysql没法利用索引完成的排序操做成为“文件排序” ，当须要排序，而又没法直接经过索引直接完成排序，须要额外的操做的时候发生using filesort。
filesort只能应用在单个表上，若是有多个表的数据须要排序，那么MySQL会先使用using temporary保存临时数据，而后再在临时表上使用filesort进行排序，最后输出结果。

---

last_query_cost

对比MySQL不一样写法或者改变了索引对象以后SQL的效率的时候，彷佛只能傻傻地看执行时间以及一个粗略的执行计划，呵呵。
IO、CPU、内存使用都看不到，而last_query_cost彷佛也不必定靠得住。
last_query_cost的单位也不是page什么的，应该是一个综合代价的值。
The Last_query_cost value can be computed accurately only for simple “flat” queries, not complex queries such as those with subqueries or UNION.
For the latter, the value is set to 0.

至于Profile或者performance_schema.events_stages_history_long 里面的信息，也就是看看sending data，也是一个综合资源消耗的时间结果。

---

Sending Data

Profile或者performance_schema.events_stages_history_long 中的Sending data
“Sending data”并非单纯的发送数据，而是包括“收集 + 发送 数据”，说白了就是查询到结果返回的整个过程，MySQL里不少命名的东西都颇有误导性，上面还在说filesort。
而performance_schema.events_stages_history_long中的绝大部分步骤，根本没法改变。
好比closing tables，cleaning up等等，自己就是查询引擎的一部分消耗，跟用户行为无关，用户也没法左右其时间消耗。

---

 

中止复制

　　reset slave 只是删除了master.onfo和reply_log.info文件，复制同步信息还在，reset slave all完全地清除复制。

---

 

 慢查询是否记录因阻塞形成超过long_query_time的查询？

　　通过测试，答案是不会。慢查询在计算“慢”的查询的时候，是只计算正常执行时间超出long_query_time的查询，而不计算阻塞的时间。
　　慢查询也不会由于超时或者其余缘由形成的失败的查询。

　　补充：在SQL Server中，相似于用于记录慢查询的trace或者扩展事件，在记录“慢查询”的时候，是会把阻塞时间也算做“慢”以内的。

---

 

MySQL中的预读

若是一个extent中的被顺序读取的page超过或者等于该参数变量的，innodb将会异步的将下一个extent读取到buffer pool中，
由参数innodb_read_ahead_threshold来控制
好比该参数的值为30，那么当该extent中有30个pages 被 sequentially的读取，则会触发innodb linear预读，将下一个extent读到内存中。

---

 

eq_range_index_dive_limit

　　MySQL中In谓词是否用索引的阈值，MySQL 5.7 默认值是200,5.6默认值是10

---

 

未完待续。