目录
一、优化硬件和操作系统（服务器问题）
从硬件层面来说，可以通过对CPU、硬盘内存、网络带宽来优化。从操作系统来说，可以优化操作系统网络配置。一般都是由运维工程师负责。
二、优化整体架构设计（高可用和性能）
MySQL是一个磁盘IO访问非常频繁的关系型数据库，如果在高并发和高性能场景下，MySQL数据库必然会承受巨大的并发压力，而此时，我们的优化方式可以分为以下几个部分：
1.搭建主从集群：单个MySQL服务容易单点故障，一旦服务器宕机，将会导致依赖MySQL数据库的应用全部无法响应。通过搭建主从集群，可以有效提高mysql的并发能力，可以保证服务的高可用性。
2.读写分离：在读多写少的场景中，通过读写分离，可以避免读写冲突的性能问题。
3.引入分库分表机制：通过分库可以降低单个服务器节点的IO压力，通过分表的方式可以降低单表数据量，从而提高查询效率。
4.针对热点数据：引入更高效的分布式数据库，比如Redis、MongoDB等NOSQL数据库，可以很好的缓解MySQL的访问压力，同时还能提升数据检索功能。
针对高并发场景下，通过搭建MySQL主从集群读写分离可解决高可用性能问题，分库分表可提升查询效率，热点数据加缓存可缓解数据库访问压力。提高数据检索速度。
三、优化MySQL配置文件（程序配置）
MySQL是一个经过互联网大厂验证过的生产级别的成熟数据库，对于MySQL本身的优化，一般是通过MySQL中的配置文件my.cnf来完成，比如：
MySQL5.7版本默认最大连接实例是151个，这个值可以在my.cnf中修改，binlog日志，缓存池默认大小配置等。
四、优化SQL语句
1.查询SQL尽量不要使用select *，而是select具体字段
2.如果知道查询结果只有一条或者只要最大/最小一条记录，建议用limit 1
3.应尽量避免在where子句中使用or来连接条件
4.优化你的like语句
5.使用where条件限定要查询的数据，避免返回多余的行
6.使用联合索引时，注意索引列的顺序，一般遵循最左匹配原则。
7.对查询进行优化，应考虑在where及order by涉及的列上建立索引，尽量避免全表扫描。
8.在适当的时候，添加覆盖索引。
9.不要有超过5个以上的表连接
10.给表起别名
12.explain分析sql执行计划
1.慢SQL的定位和排查
我们可以通过慢查询日志和慢查询日志分析工具（mysqldumpslow）得到有问题的SQL列表。
2.explain执行计划分析：
针对慢SQL,我们可以使用关键字explain来分析sql执行计划，重点关注type,key,rows，extra等字段，从而分析出SQL执行慢的根本原因。
3.使用show profile工具
Show Profile是MySQL提供的可以用来分析当前会话中，SQL语句资源消耗情况的工具，可用于
SQL调优的测量。在当前会话中.默认情况下处于show profile是关闭状态，打开之后保存最近15次
的运行结果。
针对运行慢的SQL，通过profile工具进行详细分析.可以得到SQL执行过程中所有的资源开销情况. 如IO开销,CPU开销,内存开销等.
五、遵循索引创建原则
1.查询中很少使用到的列，不加索引，避免资源浪费
2.很少数据的列也不应该建立索引。比如sex性别
3.当修改的操作大于查询的操作
4.表的主键、外键必须有索引；
5.数据量大的表应该有索引；
6.经常与其他表进行连接的表，在连接字段上应该建立索引；
7.经常出现在Where子句中的字段，特别是大表的字段，应该建立索引；
8.索引应该建在选择性高的字段上； （sex 性别这种就不适合）
9.索引应该建在小字段上，对于大的文本字段甚至超长字段，不要建索引；
10.频繁进行数据操作的表，不要建立太多的索引；
11.删除无用的索引，避免对执行计划造成负面影响；
12.表上建立的每个索引都会增加存储开销，索引对于插入、删除、更新操作也会增加处理上的开销。另外，过多的复合索引，在有单字段索引的情况下，一般都是没有存在价值的；
相反，还会降低数据增加删除时的性能，特别是对频繁更新的表来说，负面影响更大。
总结：
日常优化数据库可以从不同角度去分析，从硬件角度可以优化CPU、内存、硬盘等；从架构设计层面可以搭建主从集群；需要遵循基本表设计三范式和索引创建原则，因为索引的创建和维护都需要消耗物理空间，过度创建不必要的索引反而会造成维护困难的缺点；从sql语句分析，可以开启慢查询日志，explain分析sql执行情况，定位问题，必要时也可以使用一些sql分析工具进行辅助分析和排查问题，
386
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
