1、性能监控
1.1 自带的优化
- rbo基于规则优化
- cbo基于成本优化
2、查看sql执行时间
set profiling=1
select * from table
show profile
show profile cpu
3、表设计三范式
列不可分
不能存在传递依赖
其他列必须依赖主键
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15第一范式:确保每列的原子性(强调的是列的原子性，即列不能够再分成其他几列).
如果每列(或者每个属性)都是不可再分的最小数据单元(也称为最小的原子单元),则满足第一范式.
例如:顾客表(姓名、编号、地址、……)其中"地址"列还可以细分为国家、省、市、区等。
第二范式:在第一范式的基础上更进一层,目标是确保表中的每列都和主键相关(一是表必须有一个主键；二是没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的部分)
如果一个关系满足第一范式,并且除了主键以外的其它列,都依赖于该主键,则满足第二范式.
例如:订单表(订单编号、产品编号、定购日期、价格、……)，"订单编号"为主键，"产品编号"和主键列没有直接的关系，即"产品编号"列不依赖于主键列，应删除该列。
第三范式:在第二范式的基础上更进一层,目标是确保每列都和主键列直接相关,而不是间接相关(另外非主键列必须直接依赖于主键，不能存在传递依赖).数据不能存在传递关系，即每个属性都跟主键有直接关系而不是间接关系。
如果一个关系满足第二范式,并且表中的每一列只与主键直接相关而不是间接相关,则满足第三范式.
为了理解第三范式，需要根据Armstrong公里之一定义传递依赖。假设A、B和C是关系R的三个属性，如果A-〉B且B-〉C，则从这些函数依赖中，可以得出A-〉C，如上所述，
依赖A-〉C是传递依赖。
例如:订单表(订单编号，定购日期，顾客编号，顾客姓名，……)，初看该表没有问题，满足第二范式，每列都和主键列"订单编号"相关，再细看你会发现"顾客姓名"和"顾客
编号"相关，"顾客编号"和"订单编号"又相关，最后经过传递依赖，"顾客姓名"也和"订单编号"相关。为了满足第三范式，应去掉"顾客姓名"列，放入客户表中。
4、字符设置
- utf-8：超过三个字节的unicode字符会乱码
- utf-8mb4：解决中文使用utf-8乱码
5、数据库引擎选择
InnoDB
MyISAM
MEMORY
innodb和myisam比较
5.1 innodb选择b+树的原因：
- 避免全表扫描
- B+ 树其实能够保证数据按照键的顺序进行存储，也就是相邻的所有数据其实都是按照自然顺序排列的
- 系统读取磁盘文件为了防止抖动，都是以固定页大小进行内存读入和切出一般为4k，磁盘io是查询的瓶颈，b+树可以有效减少磁盘io次数
- 哈希虽然能够提供
O(1)的单数据行操作性能，但是对于范围查询和排序却无法很好地支持，最终导致全表扫描 - B 树能够在非叶节点中存储数据，但是这也导致在查询连续数据时可能会带来更多的随机 I/O，而 B+ 树的所有叶节点可以通过指针相互连接，能够减少顺序遍历时产生的额外随机 I/O
6、mysql索引
索引列不允许为空
索引列的数据长度能少则少
索引一定不是越多越好，越全越好，一定是建合适的
匹配列前缀可用到索引 like 9999%，like %9999%、like %9999 用不到索引
where 条件中 not in 和 <> 操作无法使用索引
匹配范围值，order by 也可用到索引
多用指定列查询，只返回自己想到的数据列，少用 select *
联合索引中如果不是按照索引最左列开始查找，无法使用索引
联合索引中精确匹配最左前列并范围匹配另外一列可以用到索引
联合索引中如果查询中有某个列的范围查询，则其右边的所有列都无法使用索引
最后更新： 2021年03月02日 13:08