企业官网建设流程全解析

优化思路

• 索引
  • 索引讲的深一点，还会涉及到回表
  • 覆盖索引
• 查询计划
  • OR 还是 IN
    • MYSQL 中的 IN 查询做了优化，其他数据库查询的时候 OR 和 IN 可能是等价的，MYSQL会对 IN 查询做优化，先排序 IN 中的元素，然后用二分查找来进行查询【时间复杂度 O(logn)】，所以效率会比 OR 高【时间复杂度 O(n)】
    • https://zhuanlan.zhihu.com/p/71064147
    • https://blog.csdn.net/Asce_zz/article/details/89000975
    • https://stackoverflow.com/questions/782915/mysql-or-vs-in-performance
  • IN的数量
    • 特别是 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-use
    • https://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?id=70247
  • 关于 filesort
    • 涉及到 limit 查询优化
    • https://zhuanlan.zhihu.com/p/101571164
    • https://segmentfault.com/a/1190000040880890
    • https://segmentfault.com/a/1190000016251056
  • 关于扫表的场景
    • 需要扫全表的时候，不要用 offset + limit 来扫描
    • 改成通过 id between min(id) max(id) 来扫描
• 慢查
  • 慢查的识别方式是MYSQL自己会有慢查询日志
• 数据库层面设计
  • 数据库分库分表，单张表的数据上限是4000w
  • 横向拓展、水平拓展，读写分离，冷热分离、主从架构