MySQL服务器性能剖析+Schema和数据类型优化

MySQL服务器性能剖析+Schema和数据类型优化

前言：
之前一直执着于怎么写好，结果好久都没写了。后面想了想，文章写得太少了，想写好其实不怎么容易，而且压力山大，都不敢去写。
现在干脆不要管花里胡哨的东西。主要写给自己看，想到什么写什么。算是复习

这篇完整是看《高性能MySQL》这本的笔记。而且是上午看完后现在（2020年4月29日21:53:43）的复习，靠脑子回想看记得多少
原笔记内容 高性能MySQL笔记 因为github访问太慢了，我用的gitee码云，和github功能一样，但是要访问这个笔记可能需要码云账号

看了两个章节

服务器性能剖析

作者对性能的核心有两个：一个是以响应时间作为性能衡量的标准；另一个是以测试的客观结果进行剖析（不是去猜问题出现在哪里，要有事实依据）

性能剖析步骤一次是：整个应用–>数据库服务器–>单个的查询
虽然有时候数据库可能是应用的瓶颈，但是这种事得有确切证据才可以，确定是数据库问题之后，对数据库服务器进行测试分析，找出消耗最长的一部分SQL进行分析，分析SQL是为什么花了太多时间

作者推荐用慢查询日志进行分析，以及用个XX工具的（名字我不记得）
开启慢查询日志

## 开启慢查询日志
set global slow_query_log = "ON";
## 当时间超过1时记录查询语句
set global long_query_time = 1;

一条语句的时间一般耗在两部分：执行查询（一般和子查询有关，看是否可以减少子查询次数），等待时间（这个有点复杂了，可能是与其他应用竞争磁盘，或者CPU）

Schema与数据类型优化

数据类型

整数：tinyint，smallint mediumint ， int，bigint
分别占用8,16,24,32,64位
int(1)和int(10)仅显示有区别，对性能没有任何优化，不要在干傻事了
实数：decimal，double，float
decimal是精确小数，没4直接存储9个数组，小数点单独一个字节
decimal(18,9)占9个字节
字符串 ：
char 定长 效率更高
varchar 变长，节省空间，但是有可能导致分裂的情况。用的UTF-8字符集，最大长度比平均长度长很多，列更新少就很适合这种
日期：datetime和timestamp。后者占用字节少4，前者得8
后者是1970-2038,18年后过期，前者1001-9999
推荐用后者，时区相关，会自动更新

范式

第一范式：每个字段不可再分割
第二范式：所有非主键都依赖于主键
第三范式：所有非主键都不依赖于非主键

范式的好处：冗余少，更新快（因为一个字段只用更新一次）
缺点：查询一般都需要连表查询，连表查询相对来说没有单表查询快

非范式的好处：与范式相反

一般结合着用

小结

• 不要过度优化，当成本查过收益时停止优化
• 要根据测试结果分析，再优化。不要拍脑袋
• 小而简单的数据类型就很好
• 如果可以，尽量不用空值
• 可以用汇总表来优化查询