ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

MYSQL慢查询优化

MYSQL慢查询优化 优化思路索引索引讲的深一点还会涉及到回表覆盖索引查询计划OR 还是 INMYSQL 中的 IN 查询做了优化其他数据库查询的时候 OR 和 IN 可能是等价的MYSQL会对 IN 查询做优化先排序 IN 中的元素然后用二分查找来进行查询【时间复杂度 O(logn)】所以效率会比 OR 高【时间复杂度 O(n)】https://zhuanlan.zhihu.com/p/71064147https://blog.csdn.net/Asce_zz/article/details/89000975https://stackoverflow.com/questions/782915/mysql-or-vs-in-performanceIN的数量特别是 MYSQL 5.6 升级到 5.7 之后对于 IN 的查询优化做了更新之前是根据 IN 的数量来判断是否走索引 8388608默认值 时会走索引大于这个数量会放弃range走全表扫描5.7 则是根据一个 range_optimizer_max_mem_size 参数判断查询所需的内存是否大于这个阈值如果大于则会放弃range走全表扫描。两个版本判断的依据不一样所以会导致查询效率变化https://dev.mysql.com/doc/refman/5.7/en/range-optimization.html#range-optimization-memory-usehttps://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-9.html《Using many WHERE conditions makes range scan disabled》https://bugs.mysql.com/bug.php?id70247关于 filesort涉及到 limit 查询优化https://zhuanlan.zhihu.com/p/101571164https://segmentfault.com/a/1190000040880890https://segmentfault.com/a/1190000016251056关于扫表的场景需要扫全表的时候不要用 offset limit 来扫描改成通过 id between min(id) max(id) 来扫描慢查慢查的识别方式是MYSQL自己会有慢查询日志数据库层面设计数据库分库分表单张表的数据上限是4000w横向拓展、水平拓展读写分离冷热分离、主从架构
返回列表