数据类型和schema优化
数据类型的优化
合理使用范式和反范式
三大范式：
1、表不可分
2、不能存在传递依赖
3、表里其他列的值必须唯一依赖于主键
约定大于规范，没有必要严格遵守范式，以业务为准，需要取舍。有时候空间换时间，没有明确的标准。
- 如果排序操作命中了索引，就不需要加载进内存中排序了，效率更高
主键的选择
自然主键
充当主键的字段本身具有一定的含义，是构成记录的组成部分，比如学生的学号，除了充当主键之外，同时也是学生记录的重要组成部分。
代理主键（推荐使用）
就是充当主键的字段本身不具有业务意义，只具有主键作用，比如UUID，主键生成器（有自己的生成策略），自增id
字符集的选择
utf-8会有只能存2个字节的中文的情况，有的中文是不能存的，因此建议使用utf8mb4
man utf-8
存储引擎的选择
存储引擎：数据文件的组织形式
my.ini 配置文件默认是Innodb
在mysql刚开始诞生的时候，并没有innodb引擎，用的是myisam引擎，它不支持事务。
innodb引擎后来被创造之后，一开始是以插件的形式运行的，但是在5.5版本之后，默认使用的是innodb存储引擎。
适当的书数据冗余
视图：Oracle有物化视图（数据更新能够及时更改）
数据冗余要保证修改时的一致性！（可以用触发器）
适当拆分
当我们的表中存在类似于 TEXT 或者是很大的 VARCHAR类型的大字段的时候，如果我们大部分访问这张表的时候都不需要这个字段，我们就该义无反顾的将其拆分到另外的独立表中，以减少常用数据所占用的存储空间。
这样做的一个明显好处就是，每个数据块中可以存储的数据条数可以大大增加，既减少物理 IO 次数，也能大大提高内存中的缓存命中率。
数据库的拆分是非常麻烦的，以后我们讲mycat的时候再详细说。
执行计划
《阿里这十年》这本书可以随便看看
索引为什么用B+数
- hash表不适合范围查询
- 8.0之后没有查询缓存了，为什么？
- 索引下推是啥？
- 画一个知识脑图
.idb是数据文件和索引文件存在一起.myd是数据文件.myi是索引文件
索引基本知识
附：MySQL8.0为什么取消了查询缓存
MySQL 8.0: Retiring Support for the Query Cache MySQL服务器团队有一篇关于此的详细博客，其中Matt Lord说：
尽管MySQL Query Cache旨在提高性能，但它存在严重的可伸缩性问题，并且很容易成为严重的瓶颈。
自MySQL 5.6（2013）以来，默认情况下已禁用查询缓存，因为众所周知，它不能与多核计算机上在高吞吐量工作负载情况下进行扩展。
我们考虑了可以对查询缓存进行哪些改进，以及我们可以进行的优化，这些优化可以改善所有工作负载。
虽然这些选择本身是正交的，但工程资源是有限的。也就是说，我们正在转变战略，投资于更普遍适用于所有工作负载的改进。
建议把缓存放到客户端
“Client + 2x ProxySQL”结果显示，在将缓存移动到客户端时，性能提高了5.2倍。
