网站首页加载时间大约为5-6秒，在后台点击一次订单列表之后就会转动十几秒钟左右，投放活动页面一经点击就会出现白屏现象——企业建站交付后最常被诟病的问题不是网页设计不够漂亮，而是速度太慢。造成这种状况的原因有一半来自于前端，另一半则隐藏在了数据库里。前端的问题很容易看出端倪来，但是数据库中的问题总是要等到“完全卡住”的时候才会被发觉。
把“慢”这个概念用一条具体的SQL语句来表示
慢查询日志就是最简单的诊断工具之一了，把long_query_time设为1秒后运行一天真实的业务数据，并且用mysqldumpslow或pt-query-digest来做统计汇总分析，在前几项出现的情况基本上就可以判断出哪里出了问题。找到了具体的语句之后再用EXPLAIN查看它的执行计划，主要注意以下三点：type是不是ALL（全表扫描）、rows估计值有没有异常、Extra里有没有Using filesort或者Using temporary等字眼。大多数性能瓶颈的问题都可以通过这一步来解决掉，并不需要依靠直觉去猜测。
索引要依据“查询路线”来构建
索引并不是越多越好，每增加一个索引就要多一次写操作去维护一棵B+树，并且磁盘空间也会随之增大。合理的顺序是：WHERE子句中的条件字段、JOIN连接条件字段、ORDER BY和GROUP BY字段先建立索引；对于区分度很小的字段（比如只有两个或者三个取值的布尔值），单独建索引效果不佳。联合索引要遵守最左原则，即按照“等值在前、范围在后”的方式排序。此外还经常出现的一种错误就是在索引列上套用了函数或者进行了隐式类型转换，从而导致索引失效——varchar类型的字段输入数字、用DATE(create_time)来过滤都属于这种情况。
SQL语句中的隐性成本
select * 是老问题了，如果把详情文本、图片地址等大数据量的字段全部查询出来之后再通过网络传输以及内存操作来处理的话就会造成资源的浪费。深翻页（limit 100000,20）会先扫描十万行数据，而采用基于主键的分页方式则更加稳定一些。当子查询嵌套层次过多时应该将其分解成两条简单的语句，在应用程序层进行拼接，这样数据库优化的效果也会更好一些。“少写一句话”的选择之中常常隐藏着许多数据库优化的机会。大批量的更新操作不应该一次性插入几万条数据，而应该分成500~1000行左右的小批次来进行提交，从而缩短锁等待的时间。
表格结构就是对数据进行瘦身
字段类型要尽量小一些：状态用tinyint表示，主键用bigint自增，并不是所有的字段都采用varchar(255)。对于大文本、JSON以及附件路径等很少用到的数据，则放在副表里保存，这样主表就可以变得比较紧凑了，每一个数据页都可以存储更多的数据行，并且提高了缓存命中率。日志、流水、操作记录等只增不改的数据每月进行一次归档或者分区处理，使得主表始终维持在千万级数据量左右的状态之下，保证网站运行速度有一个固定的下限，并不会因为订单量的增长而越来越慢。
缓存分层是为了使数据库所做的事情变少
最好的方法是不去查数据库了，在热门的数据（导航分类、商品基础信息、区域词典等等）上利用Redis来存储，并且设置合适的过期时间和主动更新机制；对于那些变化不太频繁的整体页面内容可以用静态或半静态的方式来处理；所有的图片、CSS和JS文件都要上传到CDN上去。为了避免出现缓存穿透、击穿以及雪崩的问题，需要做以下几件事情：空值也要被缓存起来；热点key在过期之后要用锁的方式重新构建；过期时间上要增加一些随机扰动。只要完成了上述工作，数据库每秒查询次数就会减少一半左右，首字节响应时间也会相应地缩短。
⚙️ 不要一直用默认值给参数赋值
云数据库开箱即用，但是默认配置比较保守。innodb_buffer_pool_size一般设为实例可用内存的60%-70%，把热数据都放到内存里去；max_connections要与应用层连接池的最大值相一致，在高峰期不然会报too many connections错误；必须启用连接复用功能，短连接每次握手认证所花的时间成本在高频率调用的时候非常高。tmp_table_size、sort_buffer_size可以按需适当调小，并不是越大越好，否则一个查询就会把整个内存给占满了。
要按时做体检，并不是出了事情之后再去医治
每周查看一次慢查询周报，每月运行一次 ANALYZE TABLE 来更新统计数据，在业务淡季的时候对碎片较多的表执行 OPTIMIZE 或者在线重建操作。只做逻辑删除会使表变得非常臃肿，冷数据要尽快移走。数据库优化不是一蹴而就的事情，在企业建立之初就要部署好监控系统：连接数、慢查询数量、缓存命中率、磁盘读写速度等等指标，并且要有趋势图以便提前预警，而不能等用户投诉后再去做。
企业创建了一个网站之后并不能一劳永逸地解决问题了，网站运行速度也是一条需要不断维护和改进的道路。索引、SQL语句、数据库表结构、缓存机制、参数优化以及定期检查这六项工作并不属于高深莫测的技术范畴，而是靠坚持不懈地去完成并且做好记录、进行比较分析——一个好的网站不是靠一次大改动就可以达到的效果，在每周减少一条低效的SQL语句、每月删掉一张多余的数据表的过程中慢慢变快——速度就是一种节约出来的东西，也是一种培养出来的东西。