介绍
Mysql优化可以分为三个层面,即设计层面,架构层面,SQL语句来进行优化.
优化原则
- 数据库在设计的时候严格按照范式设计,特殊情况下可反范式设计.
- 字段尽可能的使用小的数据类型.
- 开启慢查询,分析比较慢的SQL语句,记录下进行分析和处理.
- 使用explainSQL语句进行分,分析比较慢改写SQL语句或者针对需要的字段适当的加上索引.
- 应用层面进行优化,例如加上缓存(memcached和redis),或页面静态化,减少查询数据库次数,将效率分摊至前端方便扩展应用服务器.
- 不使用数据库进行存储过程、储发器等复杂的业务逻辑,因为压力在数据库上面,进一步减轻数据库服务器的压力.
- 架构层面进行调整,使用主从、读写分离的方式减轻数据库服务器的压力,避免在单台机器上过度消耗资源.
- 对数据库的表进行纵切,垂直分表,将不经常读的内容和经常操作的内容放置不同的表中.不经常读取内容,降低磁盘IO.
- 使用Mysql表分区,将一个表分成多个不同的文件.
- innodb本身不支持rtree索引,而支持的btree索引,对统计计数不友好.可以将统计计数专门使用一个字段来维护或使用NoSQL设计来存储.
- 按照一些具体业务场景选择存储引擎.
- 不要使用or,like,搜索的加上主键,不用或者少用全文索引.
- 将全文索引专门建立全文索引服务器ElasticSearch.
- 优化相关配置的参数.
- 可以提升机器性能例如用固态硬盘、用更大的内存.
规范设计原则
第一范式
第一范式是最基本的范式,如数据库表中的所有字段值都是不可分解的原子值,就说明该数据库表满足了第一范式.
第一范式的合理遵循需要根据系统的实际需求来定.比如某些数据库系统中需要用到'地址'这个属性,本来直接将'地址'属性设计成一个数据库表的字段就行.但是如果系统经常会访问'地址'属性中的'城市'部分,那么就非要将'地址'这个属性重新拆分为省份、城市、详细地址等多个部分进行存储,这样在对地址中某一部分操作的时候将非常方便.这样设计才算满足了数据库的第一范式.
第二范式
第二范式在第一范式的基础之上更进一层.第二范式需要确保数据库表中的每一列都和主键相关,而不能只与主键的某一部分相关(主要针对联合主键而言).也就是说在一个数据库表中,一个表中只能保存一种数据,不可以把多种数据保存在同一张数据库表中.
比如要设计一个订单信息表,因为订单中可能会有多种商品,所以要将订单编号和商品编号作为数据库表的联合主键.
第三范式
第三范式需要确保数据表中的每一列数据都和主键直接相关,而不能间接相关.比如要设计一个订单信息表,因为订单中可能会有多种商品,所以要将订单编号和商品编号作为数据库表的联合主键.
