MySQL优化基本操作

优化思路#

详细的 MySQL 优化步骤如下:

  • 检查数据表结构,改善不完善设计
  • 跑一遍主要业务,收集常用的数据库查询 SQL
  • 分析查询 SQL,适当拆分,添加索引等优化查询
  • 优化 SQL 的同时,优化代码逻辑
  • 添加本地缓存和 redis 缓存

尽可能不要使用 NULL 值#

因为建表的时候,如果不对创建的值设置默认值,MySQL 都会设置默认为 NULL。那么为啥用 NULL 不好呢?

  • NULL 使得索引维护更加复杂,强烈建议对索引列设置 NOT NULL
  • NOT IN!= 等负向条件查询在有 NULL 值的情况下返回永远为空结果,查询容易出错
  • NULL 列需要一个额外字节作为判断是否为 NULL 的标志位
  • 使用 NULL 时和该列其他的值可能不是同种类型,导致问题。(在不同的语言中表现不一样)
  • MySQL 难以优化对可为 NULL 的列的查询

所以对于那些以前偷懒的字段,手动设置一个默认值吧,空字符串呀,0 呀补上。

虽然这种方法对于 MySQL 的性能来说没有提升多少,但是这是一个好习惯,而且以小见大,不要忽略这些细节。

添加索引#

对于经常查询的字段,请加上索引,有索引和没有索引的查询速度相差十倍甚至更多。

  • 一般来说,每张表都需要有一个主键 id 字段
  • 常用于查询的字段应该设置索引
  • varchar 类型的字段,在建立索引的时候,最好指定长度
  • 查询有多个条件时,优先使用具有索引的条件
  • LIKE 条件这样的模糊搜索对于字段索引是无效的,需要另外建立关键词索引来解决
  • 请尽量不要在数据库层面约束表和表之间的关系,这些表之间的依赖应该在代码层面去解决

当表和表之间有约束时,虽然增删查的 SQL 语句变简单了,但是带来的负面效果是插入等操作数据库都会去检查约束(虽然可以手动设置忽略约束),这样相当于把一些业务逻辑写到了数据库层,不便于维护。

优化表字段结构#

数据库中那些可以用整形表示的数据就不要使用字符串类型,到底是用 varchar 还是 char 要看字段的可能值。

这种优化往往在数据库中有大量数据以后是不可行的,最好在数据库设计之前就设计好。

  • 对于那些可能值很有限的列,使用 tinyint 代替 VARCHAR
    • 比如记录移动设备平台,只有两个值:android,ios,那么就可以使用 0 表示 android,1 表示 ios,这种列一定要写好注释
    • 为什么不用 ENUM 呢?ENUM 扩展困难,比如后来移动平台又增加了一个 ipad,那岂不是懵逼了,而 tinyint 加个 2 就行,而且 ENUM 在代码里面处理起来特别奇怪,是当成整形呢还是字符串,各个语言不一样。
    • 这种方式,一定要在数据库注释或者代码里面写明各个值的含义
  • 对于那些定长字符串,可以使用 char,比如邮编,总是 5 位
  • 对于那些长度未知的字符串,使用 varchar
  • 不要滥用 bigint,比如记录文章数目的表 id 字段,用 int 就行了,21 亿篇文章上限够了
  • 适当打破数据库范式添加冗余字段,避免查询时的表连接

查询的时候,肯定 int 类型比 varchar 快,因为整数的比较直接调用底层运算器就可以实现,而字符串比较要逐个字符比较。

定长数据比变长数据查询快,因为比较定长数据与数据之间的偏移是固定的,很容易计算下一个数据的偏移。而变长数据则还需要多一步去查询下一个数据的偏移量。不过。定长数据可能会浪费更多的存储空间。

大表拆分#

对于那些数据量可能近期会超过 500W 或者增长很快的表,一定要提前做好垂直分表或者水平分表,当数据量超过百万以后,查询速度会明显下降。

分库分表尽量在数据库设计初期敲定方案,否则后期会极大增加代码复杂性而且不易更改。

垂直分表是按照日期等外部变量进行分表,水平分表是按照表中的某些字段关系,使用 hash 映射等分表。

分库分表的前提条件是在执行查询语句之前,已经知道需要查询的数据可能会落在哪一个分库和哪一个分表中。

优化查询语句#

这个才是很多系统数据库瓶颈的始作俑者。

  • 请尽量使用简单的查询,避免使用表链接
  • 请尽量避免全表扫描,会造成全表扫描的语句包括但不限于:
    • where 子句条件恒真或为空
    • 使用 LIKE
    • 使用不等操作符(<>、!=)
    • 查询含有 is null 的列
    • 在非索引列上使用 or
  • 多条件查询时,请把简单查询条件或者索引列查询置于前面
  • 请尽量指定需要查询的列,不要偷懒使用 select *
    • 如果不指定,一方面会返回多余的数据,占用带宽等
    • 另一方面 MySQL 执行查询的时候,没有字段时会先去查询表结构有哪些字段
  • 大写的查询关键字比小写快一点点
  • 使用子查询会创建临时表,会比链接(JOIN)和联合(UNION)稍慢
  • 在索引字段上查询尽量不要使用数据库函数,不便于缓存查询结果
  • 当只要一行数据时,请使用 LIMIT 1,如果数据过多,请适当设定 LIMIT,分页查询
  • 千万不要 ORDER BY RAND (),性能极低

添加缓存#

使用 redis 等缓存,还有本地文件缓存等,可以极大地减少数据库查询次数。缓存这个东西,一定要分析自己系统的数据特点,适当选择。

  • 对于一些常用的数据,比如配置信息等,可以放在缓存中
  • 可以在本地缓存数据库的表结构
  • 缓存的数据一定要注意及时更新,还有设置有效期
  • 增加缓存务必会增加系统复杂性,一定要注意权衡

检查数据表结构#


转载:www.cnblogs.com/youyoui/p/8657331....

本作品采用《CC 协议》,转载必须注明作者和本文链接
讨论数量: 1

我觉得数据库设计初期没必要太复杂考虑太多,除非公司本身很大,可预计用户数量的情况下确实可以,不然感觉更据业务来变更更可靠,后期可以将数据慢慢转移嘛。其它还是挺好的。

3年前 评论
WuTao_lxm (楼主) 3年前