从硬件角度考虑
- CPU, 可以让SQL语句解析得更快，进而加快SQL语句的执行速度。
- 内存, 可以缓存更多的MySQL数据在内存中，进而加快MySQL的数据读取速度。
- 硬盘, 可以让MySQL更快的读取和写入数据，进而加快SQL语句的响应速度。
- 网络资源, 高的网络带宽，能让MySQL提供更大的吞吐量，进而加快客户端与MySQL服务器之间的数据传输速度。
从软件角度考虑
- 如果是高并发的业务, 达到一定量级, 只要消耗的成本大于二次深度定制mysql的研发成本, 完全可以根据自身业务重新改写mysql内部组件, 例如: 改掉mysql默认优化规则, 去掉mysql缓存, 将mysql缓存与redis缓存直接整合, 省去应用层面缓存操作等等;
- 调整mysql服务端的线程池, 缓存配置, 针对不同的场景, 采用合理的存储引擎等
- 至于调整多少, 需要根据硬件服务器的水平来进行调整, 压测. 还有操作系统本身也应该适当优化, 如: 授权mysql进程最大能同时打开的句柄数等
从表结构设计
- 将不常用的字段, 拆分到子表中, 子表中使用外键关联主表的主键
- 设计一些冗余的字段, 尽量能通过单表查询的操作, 就不要多表连接查询
- 针对高频查询的字段, 建立索引
从sql角度考虑
-
通过explain工具分析sql执行计划, 通过开启慢查询捕获性能低的SQL语句, 然后进行分析和优化. 通常是考虑充分利用索引, 避免索引失效这些问题
-
其他需要注意的是, 在日常使用中,但凡涉及到大量数据更新, 表结构修改等操作, 都要慎重考虑, 根据实际情况来处理.
-
避免使用某些关键字, 如:
orin -
避免全表扫描, 如:
select *, -
考虑索引创建的合理性, 如:性别 就没必要
-
对于数据量过大的, 考虑水平分库分表
-
对于数据包含字段太多, 考虑垂直分库分表
-
避免强制类型转换
