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进行排序，最后输出结果。

---

show status like '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或者p
“Sending data”并不是单纯的发送数据，而是包括“收集 + 发送 数据”，说白了就是查询到结果返回的整个过程，MySQL里很多命名的东西都很有误导性，上面还在说filesort。
而performance_schema.events_stages_history_long中的绝大部分步骤，根本无法改变。
比如closing tables，cleaning up等等，本身就是查询引擎的一部分消耗，跟用户行为无关，用户也无法左右其时间消耗。

---

 

 

 

 

 

未完待续。