From 8af31477f9ae9973bbdf62fa6b1b38be84daff7c Mon Sep 17 00:00:00 2001 From: guide Date: Fri, 26 Aug 2022 11:09:09 +0800 Subject: [PATCH] =?UTF-8?q?[docs=20update]MySQL=E9=AB=98=E6=80=A7=E8=83=BD?= =?UTF-8?q?=E4=BC=98=E5=8C=96=E8=A7=84=E8=8C=83=E5=BB=BA=E8=AE=AE=E6=80=BB?= =?UTF-8?q?=E7=BB=93?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...imization-specification-recommendations.md | 233 ++++++++---------- docs/database/mysql/mysql-questions-01.md | 29 +++ .../some-thoughts-on-database-storage-time.md | 16 +- 3 files changed, 138 insertions(+), 140 deletions(-) diff --git a/docs/database/mysql/mysql-high-performance-optimization-specification-recommendations.md b/docs/database/mysql/mysql-high-performance-optimization-specification-recommendations.md index b87d8a18..a704019e 100644 --- a/docs/database/mysql/mysql-high-performance-optimization-specification-recommendations.md +++ b/docs/database/mysql/mysql-high-performance-optimization-specification-recommendations.md @@ -1,47 +1,50 @@ --- -title: MySQL高性能优化规范建议 +title: MySQL高性能优化规范建议总结 category: 数据库 tag: - MySQL --- -> 作者: 听风，原文地址: 。JavaGuide 已获得作者授权。 +> 作者: 听风 原文地址: 。 +> +> JavaGuide 已获得作者授权，并对原文内容进行了完善。 ## 数据库命令规范 - 所有数据库对象名称必须使用小写字母并用下划线分割 - 所有数据库对象名称禁止使用 MySQL 保留关键字（如果表名中包含关键字查询时，需要将其用单引号括起来） - 数据库对象的命名要能做到见名识意，并且最后不要超过 32 个字符 -- 临时库表必须以 tmp_为前缀并以日期为后缀，备份表必须以 bak_为前缀并以日期 (时间戳) 为后缀 +- 临时库表必须以 `tmp_` 为前缀并以日期为后缀，备份表必须以 `bak_` 为前缀并以日期 (时间戳) 为后缀 - 所有存储相同数据的列名和列类型必须一致（一般作为关联列，如果查询时关联列类型不一致会自动进行数据类型隐式转换，会造成列上的索引失效，导致查询效率降低） ------- - ## 数据库基本设计规范 -### 1. 所有表必须使用 Innodb 存储引擎 +### 所有表必须使用 InnoDB 存储引擎 -没有特殊要求（即 Innodb 无法满足的功能如：列存储，存储空间数据等）的情况下，所有表必须使用 Innodb 存储引擎（MySQL5.5 之前默认使用 Myisam，5.6 以后默认的为 Innodb）。 +没有特殊要求（即 InnoDB 无法满足的功能如：列存储，存储空间数据等）的情况下，所有表必须使用 InnoDB 存储引擎（MySQL5.5 之前默认使用 Myisam，5.6 以后默认的为 InnoDB）。 -Innodb 支持事务，支持行级锁，更好的恢复性，高并发下性能更好。 +InnoDB 支持事务，支持行级锁，更好的恢复性，高并发下性能更好。 -### 2. 数据库和表的字符集统一使用 UTF8 +### 数据库和表的字符集统一使用 UTF8 兼容性更好，统一字符集可以避免由于字符集转换产生的乱码，不同的字符集进行比较前需要进行转换会造成索引失效，如果数据库中有存储 emoji 表情的需要，字符集需要采用 utf8mb4 字符集。 -参考文章：[MySQL 字符集不一致导致索引失效的一个真实案例](https://blog.csdn.net/horses/article/details/107243447) +参考文章： -### 3. 所有表和字段都需要添加注释 +- [MySQL 字符集不一致导致索引失效的一个真实案例](https://blog.csdn.net/horses/article/details/107243447) +- [MySQL 字符集详解](https://javaguide.cn/database/character-set.html) + +### 所有表和字段都需要添加注释 使用 comment 从句添加表和列的备注，从一开始就进行数据字典的维护 -### 4. 尽量控制单表数据量的大小,建议控制在 500 万以内。 +### 尽量控制单表数据量的大小，建议控制在 500 万以内 500 万并不是 MySQL 数据库的限制，过大会造成修改表结构，备份，恢复都会有很大的问题。 可以用历史数据归档（应用于日志数据），分库分表（应用于业务数据）等手段来控制数据量大小 -### 5. 谨慎使用 MySQL 分区表 +### 谨慎使用 MySQL 分区表 分区表在物理上表现为多个文件，在逻辑上表现为一个表； @@ -49,97 +52,86 @@ Innodb 支持事务，支持行级锁，更好的恢复性，高并发下性能 建议采用物理分表的方式管理大数据。 -### 6.尽量做到冷热数据分离,减小表的宽度 +### 经常一起使用的列放到一个表中 -> MySQL 限制每个表最多存储 4096 列，并且每一行数据的大小不能超过 65535 字节。 +避免更多的关联操作。 -减少磁盘 IO,保证热数据的内存缓存命中率（表越宽，把表装载进内存缓冲池时所占用的内存也就越大,也会消耗更多的 IO）； +### 禁止在表中建立预留字段 -更有效的利用缓存，避免读入无用的冷数据； +- 预留字段的命名很难做到见名识义。 +- 预留字段无法确认存储的数据类型，所以无法选择合适的类型。 +- 对预留字段类型的修改，会对表进行锁定。 -经常一起使用的列放到一个表中（避免更多的关联操作）。 +### 禁止在数据库中存储文件（比如图片）这类大的二进制数据 -### 7. 禁止在表中建立预留字段 +在数据库中存储文件会严重影响数据库性能，消耗过多存储空间。 -预留字段的命名很难做到见名识义。 +文件（比如图片）这类大的二进制数据通常存储于文件服务器，数据库只存储文件地址信息 -预留字段无法确认存储的数据类型，所以无法选择合适的类型。 +### 禁止在线上做数据库压力测试 -对预留字段类型的修改，会对表进行锁定。 +### 禁止从开发环境,测试环境直接连接生产环境数据库 -### 8. 禁止在数据库中存储图片,文件等大的二进制数据 - -通常文件很大，会短时间内造成数据量快速增长，数据库进行数据库读取时，通常会进行大量的随机 IO 操作，文件很大时，IO 操作很耗时。 - -通常存储于文件服务器，数据库只存储文件地址信息 - -### 9. 禁止在线上做数据库压力测试 - -### 10. 禁止从开发环境,测试环境直接连接生产环境数据库 - ------- +安全隐患极大，要对生产环境抱有敬畏之心！ ## 数据库字段设计规范 -### 1. 优先选择符合存储需要的最小的数据类型 +### 优先选择符合存储需要的最小的数据类型 -**原因：** +存储字节越小，占用也就空间越小，性能也越好。 -列的字段越大，建立索引时所需要的空间也就越大，这样一页中所能存储的索引节点的数量也就越少也越少，在遍历时所需要的 IO 次数也就越多，索引的性能也就越差。 +**a.某些字符串可以转换成数字类型存储比如可以将 IP 地址转换成整形数据。** -**方法：** - -**a.将字符串转换成数字类型存储,如:将 IP 地址转换成整形数据** +数字是连续的，性能更好，占用空间也更小。 MySQL 提供了两个方法来处理 ip 地址 -- inet_aton 把 ip 转为无符号整型 (4-8 位) -- inet_ntoa 把整型的 ip 转为地址 +- `INET_ATON()` ： 把 ip 转为无符号整型 (4-8 位) +- `INET_NTOA()` :把整型的 ip 转为地址 -插入数据前，先用 inet_aton 把 ip 地址转为整型，可以节省空间，显示数据时，使用 inet_ntoa 把整型的 ip 地址转为地址显示即可。 +插入数据前，先用 `INET_ATON()` 把 ip 地址转为整型，显示数据时，使用 `INET_NTOA()` 把整型的 ip 地址转为地址显示即可。 -**b.对于非负型的数据 (如自增 ID,整型 IP) 来说,要优先使用无符号整型来存储** - -**原因：** +**b.对于非负型的数据 (如自增 ID,整型 IP，年龄) 来说,要优先使用无符号整型来存储。** 无符号相对于有符号可以多出一倍的存储空间 -``` +```sql SIGNED INT -2147483648~2147483647 UNSIGNED INT 0~4294967295 ``` -VARCHAR(N) 中的 N 代表的是字符数，而不是字节数，使用 UTF8 存储 255 个汉字 Varchar(255)=765 个字节。**过大的长度会消耗更多的内存。** +**c.小数值类型（比如年龄、状态表示如 0/1）优先使用 TINYINT 类型。** -### 2. 避免使用 TEXT,BLOB 数据类型，最常见的 TEXT 类型可以存储 64k 的数据 +### 避免使用 TEXT,BLOB 数据类型，最常见的 TEXT 类型可以存储 64k 的数据 -**a. 建议把 BLOB 或是 TEXT 列分离到单独的扩展表中** +**a. 建议把 BLOB 或是 TEXT 列分离到单独的扩展表中。** MySQL 内存临时表不支持 TEXT、BLOB 这样的大数据类型，如果查询中包含这样的数据，在排序等操作时，就不能使用内存临时表，必须使用磁盘临时表进行。而且对于这种数据，MySQL 还是要进行二次查询，会使 sql 性能变得很差，但是不是说一定不能使用这样的数据类型。 -如果一定要使用，建议把 BLOB 或是 TEXT 列分离到单独的扩展表中，查询时一定不要使用 select * 而只需要取出必要的列，不需要 TEXT 列的数据时不要对该列进行查询。 +如果一定要使用，建议把 BLOB 或是 TEXT 列分离到单独的扩展表中，查询时一定不要使用 `select *`而只需要取出必要的列，不需要 TEXT 列的数据时不要对该列进行查询。 **2、TEXT 或 BLOB 类型只能使用前缀索引** -因为[MySQL](https://mp.weixin.qq.com/s?__biz=MzI4Njc5NjM1NQ==&mid=2247487885&idx=1&sn=65b1bf5f7d4505502620179669a9c2df&chksm=ebd62ea1dca1a7b7bf884bcd9d538d78ba064ee03c09436ca8e57873b1d98a55afd6d7884cfc&scene=21#wechat_redirect) 对索引字段长度是有限制的，所以 TEXT 类型只能使用前缀索引，并且 TEXT 列上是不能有默认值的 +因为 MySQL 对索引字段长度是有限制的，所以 TEXT 类型只能使用前缀索引，并且 TEXT 列上是不能有默认值的 -### 3. 避免使用 ENUM 类型 +### 避免使用 ENUM 类型 -修改 ENUM 值需要使用 ALTER 语句 +- 修改 ENUM 值需要使用 ALTER 语句； +- ENUM 类型的 ORDER BY 操作效率低，需要额外操作； +- ENUM 数据类型存在一些限制比如建议不要使用数值作为 ENUM 的枚举值。 -ENUM 类型的 ORDER BY 操作效率低，需要额外操作 +相关阅读：[是否推荐使用 MySQL 的 enum 类型？ - 架构文摘 - 知乎](https://www.zhihu.com/question/404422255/answer/1661698499) 。 -禁止使用数值作为 ENUM 的枚举值 +### 尽可能把所有列定义为 NOT NULL -### 4. 尽可能把所有列定义为 NOT NULL +除非有特别的原因使用 NULL 值，应该总是让字段保持 NOT NULL。 -**原因：** +- 索引 NULL 列需要额外的空间来保存，所以要占用更多的空间； +- 进行比较和计算时要对 NULL 值做特别的处理。 -索引 NULL 列需要额外的空间来保存，所以要占用更多的空间 +相关阅读：[技术分享 | MySQL 默认值选型（是空，还是 NULL）](https://opensource.actionsky.com/20190710-mysql/) 。 -进行比较和计算时要对 NULL 值做特别的处理 - -### 5. 使用 TIMESTAMP(4 个字节) 或 DATETIME 类型 (8 个字节) 存储时间 +### 使用 TIMESTAMP(4 个字节) 或 DATETIME 类型 (8 个字节) 存储时间 TIMESTAMP 存储的时间范围 1970-01-01 00:00:01 ~ 2038-01-19-03:14:07 @@ -152,22 +144,18 @@ TIMESTAMP 占用 4 字节和 INT 相同，但比 INT 可读性高 - 缺点 1：无法用日期函数进行计算和比较 - 缺点 2：用字符串存储日期要占用更多的空间 -### 6. 同财务相关的金额类数据必须使用 decimal 类型 +### 同财务相关的金额类数据必须使用 decimal 类型 -- 非精准浮点：float,double -- 精准浮点：decimal +- **非精准浮点** ：float,double +- **精准浮点** ：decimal -Decimal 类型为精准浮点数，在计算时不会丢失精度 +decimal 类型为精准浮点数，在计算时不会丢失精度。占用空间由定义的宽度决定，每 4 个字节可以存储 9 位数字，并且小数点要占用一个字节。并且，decimal 可用于存储比 bigint 更大的整型数据 -占用空间由定义的宽度决定，每 4 个字节可以存储 9 位数字，并且小数点要占用一个字节 - -可用于存储比 bigint 更大的整型数据 - ------- +不过， 由于 decimal 需要额外的空间和计算开销，应该尽量只在需要对数据进行精确计算时才使用 decimal 。 ## 索引设计规范 -### 1. 限制每张表上的索引数量,建议单张表索引不超过 5 个 +### 限制每张表上的索引数量,建议单张表索引不超过 5 个 索引并不是越多越好！索引可以提高效率同样可以降低效率。 @@ -175,32 +163,32 @@ Decimal 类型为精准浮点数，在计算时不会丢失精度 因为 MySQL 优化器在选择如何优化查询时，会根据统一信息，对每一个可以用到的索引来进行评估，以生成出一个最好的执行计划，如果同时有很多个索引都可以用于查询，就会增加 MySQL 优化器生成执行计划的时间，同样会降低查询性能。 -### 2. 禁止给表中的每一列都建立单独的索引 +### 禁止使用全文索引 + +全文索引不适用于 OLTP 场景。 + +### 禁止给表中的每一列都建立单独的索引 5.6 版本之前，一个 sql 只能使用到一个表中的一个索引，5.6 以后，虽然有了合并索引的优化方式，但是还是远远没有使用一个联合索引的查询方式好。 -### 3. 每个 Innodb 表必须有个主键 +### 每个 InnoDB 表必须有个主键 -Innodb 是一种索引组织表：数据的存储的逻辑顺序和索引的顺序是相同的。每个表都可以有多个索引，但是表的存储顺序只能有一种。 +InnoDB 是一种索引组织表：数据的存储的逻辑顺序和索引的顺序是相同的。每个表都可以有多个索引，但是表的存储顺序只能有一种。 -Innodb 是按照主键索引的顺序来组织表的 +InnoDB 是按照主键索引的顺序来组织表的 - 不要使用更新频繁的列作为主键，不适用多列主键（相当于联合索引） - 不要使用 UUID,MD5,HASH,字符串列作为主键（无法保证数据的顺序增长） - 主键建议使用自增 ID 值 ------- - -### 4. 常见索引列建议 +### 常见索引列建议 - 出现在 SELECT、UPDATE、DELETE 语句的 WHERE 从句中的列 - 包含在 ORDER BY、GROUP BY、DISTINCT 中的字段 - 并不要将符合 1 和 2 中的字段的列都建立一个索引， 通常将 1、2 中的字段建立联合索引效果更好 - 多表 join 的关联列 ------- - -### 5.如何选择索引列的顺序 +### 如何选择索引列的顺序 建立索引的目的是：希望通过索引进行数据查找，减少随机 IO，增加查询性能 ，索引能过滤出越少的数据，则从磁盘中读入的数据也就越少。 @@ -208,27 +196,23 @@ Innodb 是按照主键索引的顺序来组织表的 - 尽量把字段长度小的列放在联合索引的最左侧（因为字段长度越小，一页能存储的数据量越大，IO 性能也就越好） - 使用最频繁的列放到联合索引的左侧（这样可以比较少的建立一些索引） ------- - -### 6. 避免建立冗余索引和重复索引（增加了查询优化器生成执行计划的时间） +### 避免建立冗余索引和重复索引（增加了查询优化器生成执行计划的时间） - 重复索引示例：primary key(id)、index(id)、unique index(id) - 冗余索引示例：index(a,b,c)、index(a,b)、index(a) ------- - -### 7. 对于频繁的查询优先考虑使用覆盖索引 +### 对于频繁的查询优先考虑使用覆盖索引 > 覆盖索引：就是包含了所有查询字段 (where,select,order by,group by 包含的字段) 的索引 **覆盖索引的好处：** -- **避免 Innodb 表进行索引的二次查询:** Innodb 是以聚集索引的顺序来存储的，对于 Innodb 来说，二级索引在叶子节点中所保存的是行的主键信息，如果是用二级索引查询数据的话，在查找到相应的键值后，还要通过主键进行二次查询才能获取我们真实所需要的数据。而在覆盖索引中，二级索引的键值中可以获取所有的数据，避免了对主键的二次查询 ，减少了 IO 操作，提升了查询效率。 +- **避免 InnoDB 表进行索引的二次查询:** InnoDB 是以聚集索引的顺序来存储的，对于 InnoDB 来说，二级索引在叶子节点中所保存的是行的主键信息，如果是用二级索引查询数据的话，在查找到相应的键值后，还要通过主键进行二次查询才能获取我们真实所需要的数据。而在覆盖索引中，二级索引的键值中可以获取所有的数据，避免了对主键的二次查询 ，减少了 IO 操作，提升了查询效率。 - **可以把随机 IO 变成顺序 IO 加快查询效率:** 由于覆盖索引是按键值的顺序存储的，对于 IO 密集型的范围查找来说，对比随机从磁盘读取每一行的数据 IO 要少的多，因此利用覆盖索引在访问时也可以把磁盘的随机读取的 IO 转变成索引查找的顺序 IO。 ------- +--- -### 8.索引 SET 规范 +### 索引 SET 规范 **尽量避免使用外键约束** @@ -236,11 +220,9 @@ Innodb 是按照主键索引的顺序来组织表的 - 外键可用于保证数据的参照完整性，但建议在业务端实现 - 外键会影响父表和子表的写操作从而降低性能 ------- - ## 数据库 SQL 开发规范 -### 1. 建议使用预编译语句进行数据库操作 +### 建议使用预编译语句进行数据库操作 预编译语句可以重复使用这些计划，减少 SQL 编译所需要的时间，还可以解决动态 SQL 所带来的 SQL 注入的问题。 @@ -248,7 +230,7 @@ Innodb 是按照主键索引的顺序来组织表的 相同语句可以一次解析，多次使用，提高处理效率。 -### 2. 避免数据类型的隐式转换 +### 避免数据类型的隐式转换 隐式转换会导致索引失效如: @@ -256,9 +238,9 @@ Innodb 是按照主键索引的顺序来组织表的 select name,phone from customer where id = '111'; ``` -详细解读可以看：[MySQL中的隐式转换造成的索引失效](./index-invalidation-caused-by-implicit-conversion.md) 这篇文章。 +详细解读可以看：[MySQL 中的隐式转换造成的索引失效](./index-invalidation-caused-by-implicit-conversion.md) 这篇文章。 -### 3. 充分利用表上已经存在的索引 +### 充分利用表上已经存在的索引 避免使用双%号的查询条件。如：`a like '%123%'`，（如果无前置%,只有后置%，是可以用到列上的索引的） @@ -266,47 +248,39 @@ select name,phone from customer where id = '111'; 在定义联合索引时，如果 a 列要用到范围查找的话，就要把 a 列放到联合索引的右侧，使用 left join 或 not exists 来优化 not in 操作，因为 not in 也通常会使用索引失效。 -### 4. 数据库设计时，应该要对以后扩展进行考虑 - -### 5. 程序连接不同的数据库使用不同的账号，禁止跨库查询 +### 程序连接不同的数据库使用不同的账号，禁止跨库查询 - 为数据库迁移和分库分表留出余地 - 降低业务耦合度 - 避免权限过大而产生的安全风险 -### 6. 禁止使用 SELECT * 必须使用 SELECT <字段列表> 查询 +### 禁止使用 SELECT \* 必须使用 SELECT <字段列表> 查询 -**原因：** +- `SELECT *` 消耗更多的 CPU 和 IO 以网络带宽资源 +- `SELECT *` 无法使用覆盖索引 +- `SELECT <字段列表>` 可减少表结构变更带来的影响 -- 消耗更多的 CPU 和 IO 以网络带宽资源 -- 无法使用覆盖索引 -- 可减少表结构变更带来的影响 - -### 7. 禁止使用不含字段列表的 INSERT 语句 +### 禁止使用不含字段列表的 INSERT 语句 如： -``` +```sql insert into t values ('a','b','c'); ``` 应使用： -``` +```sql insert into t(c1,c2,c3) values ('a','b','c'); ``` -### 8. 避免使用子查询，可以把子查询优化为 join 操作 +### 避免使用子查询，可以把子查询优化为 join 操作 通常子查询在 in 子句中，且子查询中为简单 SQL(不包含 union、group by、order by、limit 从句) 时,才可以把子查询转化为关联查询进行优化。 -**子查询性能差的原因：** +**子查询性能差的原因：** 子查询的结果集无法使用索引，通常子查询的结果集会被存储到临时表中，不论是内存临时表还是磁盘临时表都不会存在索引，所以查询性能会受到一定的影响。特别是对于返回结果集比较大的子查询，其对查询性能的影响也就越大。由于子查询会产生大量的临时表也没有索引，所以会消耗过多的 CPU 和 IO 资源，产生大量的慢查询。 -子查询的结果集无法使用索引，通常子查询的结果集会被存储到临时表中，不论是内存临时表还是磁盘临时表都不会存在索引，所以查询性能会受到一定的影响。特别是对于返回结果集比较大的子查询，其对查询性能的影响也就越大。 - -由于子查询会产生大量的临时表也没有索引，所以会消耗过多的 CPU 和 IO 资源，产生大量的慢查询。 - -### 9. 避免使用 JOIN 关联太多的表 +### 避免使用 JOIN 关联太多的表 对于 MySQL 来说，是存在关联缓存的，缓存的大小可以由 join_buffer_size 参数进行设置。 @@ -316,57 +290,54 @@ insert into t(c1,c2,c3) values ('a','b','c'); 同时对于关联操作来说，会产生临时表操作，影响查询效率，MySQL 最多允许关联 61 个表，建议不超过 5 个。 -### 10. 减少同数据库的交互次数 +### 减少同数据库的交互次数 数据库更适合处理批量操作，合并多个相同的操作到一起，可以提高处理效率。 -### 11. 对应同一列进行 or 判断时，使用 in 代替 or +### 对应同一列进行 or 判断时，使用 in 代替 or in 的值不要超过 500 个，in 操作可以更有效的利用索引，or 大多数情况下很少能利用到索引。 -### 12. 禁止使用 order by rand() 进行随机排序 +### 禁止使用 order by rand() 进行随机排序 order by rand() 会把表中所有符合条件的数据装载到内存中，然后在内存中对所有数据根据随机生成的值进行排序，并且可能会对每一行都生成一个随机值，如果满足条件的数据集非常大，就会消耗大量的 CPU 和 IO 及内存资源。 推荐在程序中获取一个随机值，然后从数据库中获取数据的方式。 -### 13. WHERE 从句中禁止对列进行函数转换和计算 +### WHERE 从句中禁止对列进行函数转换和计算 对列进行函数转换或计算时会导致无法使用索引 **不推荐：** -``` +```sql where date(create_time)='20190101' ``` **推荐：** -``` +```sql where create_time >= '20190101' and create_time < '20190102' ``` -### 14. 在明显不会有重复值时使用 UNION ALL 而不是 UNION +### 在明显不会有重复值时使用 UNION ALL 而不是 UNION - UNION 会把两个结果集的所有数据放到临时表中后再进行去重操作 - UNION ALL 不会再对结果集进行去重操作 -### 15. 拆分复杂的大 SQL 为多个小 SQL +### 拆分复杂的大 SQL 为多个小 SQL - 大 SQL 逻辑上比较复杂，需要占用大量 CPU 进行计算的 SQL - MySQL 中，一个 SQL 只能使用一个 CPU 进行计算 - SQL 拆分后可以通过并行执行来提高处理效率 ------- - ## 数据库操作行为规范 -### 1. 超 100 万行的批量写 (UPDATE,DELETE,INSERT) 操作,要分批多次进行操作 +### 超 100 万行的批量写 (UPDATE,DELETE,INSERT) 操作,要分批多次进行操作 **大批量操作可能会造成严重的主从延迟** -主从环境中,大批量操作可能会造成严重的主从延迟，大批量的写操作一般都需要执行一定长的时间， -而只有当主库上执行完成后，才会在其他从库上执行，所以会造成主库与从库长时间的延迟情况 +主从环境中,大批量操作可能会造成严重的主从延迟，大批量的写操作一般都需要执行一定长的时间，而只有当主库上执行完成后，才会在其他从库上执行，所以会造成主库与从库长时间的延迟情况 **binlog 日志为 row 格式时会产生大量的日志** @@ -378,7 +349,7 @@ where create_time >= '20190101' and create_time < '20190102' 特别是长时间的阻塞会占满所有数据库的可用连接，这会使生产环境中的其他应用无法连接到数据库，因此一定要注意大批量写操作要进行分批 -### 2. 对于大表使用 pt-online-schema-change 修改表结构 +### 对于大表使用 pt-online-schema-change 修改表结构 - 避免大表修改产生的主从延迟 - 避免在对表字段进行修改时进行锁表 @@ -387,12 +358,12 @@ where create_time >= '20190101' and create_time < '20190102' pt-online-schema-change 它会首先建立一个与原表结构相同的新表，并且在新表上进行表结构的修改，然后再把原表中的数据复制到新表中，并在原表中增加一些触发器。把原表中新增的数据也复制到新表中，在行所有数据复制完成之后，把新表命名成原表，并把原来的表删除掉。把原来一个 DDL 操作，分解成多个小的批次进行。 -### 3. 禁止为程序使用的账号赋予 super 权限 +### 禁止为程序使用的账号赋予 super 权限 - 当达到最大连接数限制时，还运行 1 个有 super 权限的用户连接 - super 权限只能留给 DBA 处理问题的账号使用 -### 4. 对于程序连接数据库账号,遵循权限最小原则 +### 对于程序连接数据库账号,遵循权限最小原则 - 程序使用数据库账号只能在一个 DB 下使用，不准跨库 - 程序使用的账号原则上不准有 drop 权限 diff --git a/docs/database/mysql/mysql-questions-01.md b/docs/database/mysql/mysql-questions-01.md index d2ddde88..7e99e08b 100644 --- a/docs/database/mysql/mysql-questions-01.md +++ b/docs/database/mysql/mysql-questions-01.md @@ -452,6 +452,35 @@ UPDATE... DELETE... ``` +## MySQL 性能优化 + +关于 MySQL 性能优化的建议总结，请看这篇文章：[MySQL高性能优化规范建议总结](./mysql-high-performance-optimization-specification-recommendations.md) 。 + +### 能用 MySQL 直接存储文件（比如图片）吗？ + +可以是可以，直接存储文件对应的二进制数据即可。不过，还是建议不要在数据库中存储文件，会严重影响数据库性能，消耗过多存储空间。 + +可以选择使用云服务厂商提供的开箱即用的文件存储服务，成熟稳定，价格也比较低。 + +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/github/javaguide/mysql/oss-search.png) + +也可以选择自建文件存储服务，实现起来也不难，基于FastDFS、MinIO（推荐） 等开源项目就可以实现分布式文件服务。 + +**数据库只存储文件地址信息，文件由文件存储服务负责存储。** + +相关阅读：[Spring Boot 整合 MinIO 实现分布式文件服务，真香！](https://mp.weixin.qq.com/s/xfYCESLOuq3_0e3SFj6ZMQ) 。 + +### MySQL 如何存储 IP 地址？ + +可以将 IP 地址转换成整形数据存储，性能更好，占用空间也更小。 + +MySQL 提供了两个方法来处理 ip 地址 + +- `INET_ATON()` ： 把 ip 转为无符号整型 (4-8 位) +- `INET_NTOA()` :把整型的 ip 转为地址 + +插入数据前，先用 `INET_ATON()` 把 ip 地址转为整型，显示数据时，使用 `INET_NTOA()` 把整型的 ip 地址转为地址显示即可。 + ## 参考 - 《高性能 MySQL》第 7 章 MySQL 高级特性 diff --git a/docs/database/mysql/some-thoughts-on-database-storage-time.md b/docs/database/mysql/some-thoughts-on-database-storage-time.md index 1141ed57..694c9c22 100644 --- a/docs/database/mysql/some-thoughts-on-database-storage-time.md +++ b/docs/database/mysql/some-thoughts-on-database-storage-time.md @@ -5,13 +5,11 @@ tag: - MySQL --- - - 我们平时开发中不可避免的就是要存储时间，比如我们要记录操作表中这条记录的时间、记录转账的交易时间、记录出发时间等等。你会发现时间这个东西与我们开发的联系还是非常紧密的，用的好与不好会给我们的业务甚至功能带来很大的影响。所以，我们有必要重新出发，好好认识一下这个东西。 这是一篇短小精悍的文章，仔细阅读一定能学到不少东西！ -### 1.切记不要用字符串存储日期 +## 不要用字符串存储日期 我记得我在大学的时候就这样干过，而且现在很多对数据库不太了解的新手也会这样干，可见，这种存储日期的方式的优点还是有的，就是简单直白，容易上手。 @@ -20,13 +18,13 @@ tag: 1. 字符串占用的空间更大！ 2. 字符串存储的日期效率比较低（逐个字符进行比对），无法用日期相关的 API 进行计算和比较。 -### 2.Datetime 和 Timestamp 之间抉择 +## Datetime 和 Timestamp 之间抉择 Datetime 和 Timestamp 是 MySQL 提供的两种比较相似的保存时间的数据类型。他们两者究竟该如何选择呢？ **通常我们都会首选 Timestamp。** 下面说一下为什么这样做! -#### 2.1 DateTime 类型没有时区信息 +### DateTime 类型没有时区信息 **DateTime 类型是没有时区信息的（时区无关）** ，DateTime 类型保存的时间都是当前会话所设置的时区对应的时间。这样就会有什么问题呢？当你的时区更换之后，比如你的服务器更换地址或者更换客户端连接时区设置的话，就会导致你从数据库中读出的时间错误。不要小看这个问题，很多系统就是因为这个问题闹出了很多笑话。 @@ -100,7 +98,7 @@ SET GLOBAL time_zone = '+8:00'; SET GLOBAL time_zone = 'Europe/Helsinki'; ``` -#### 2.2 DateTime 类型耗费空间更大 +### DateTime 类型耗费空间更大 Timestamp 只需要使用 4 个字节的存储空间，但是 DateTime 需要耗费 8 个字节的存储空间。但是，这样同样造成了一个问题，Timestamp 表示的时间范围更小。 @@ -109,7 +107,7 @@ Timestamp 只需要使用 4 个字节的存储空间，但是 DateTime 需要耗 > Timestamp 在不同版本的 MySQL 中有细微差别。 -### 3 再看 MySQL 日期类型存储空间 +## 再看 MySQL 日期类型存储空间 下图是 MySQL 5.6 版本中日期类型所占的存储空间： @@ -119,7 +117,7 @@ Timestamp 只需要使用 4 个字节的存储空间，但是 DateTime 需要耗 为了方便，本文我们还是默认 Timestamp 只需要使用 4 个字节的存储空间，但是 DateTime 需要耗费 8 个字节的存储空间。 -### 4.数值型时间戳是更好的选择吗？ +## 数值型时间戳是更好的选择吗？ 很多时候，我们也会使用 int 或者 bigint 类型的数值也就是时间戳来表示时间。 @@ -149,7 +147,7 @@ mysql> select FROM_UNIXTIME(1578707612); 1 row in set (0.01 sec) ``` -### 5.总结 +## 总结 MySQL 中时间到底怎么存储才好？Datetime?Timestamp? 数值保存的时间戳？