1. 字段类型bigdecimal
bigdecimal(p,d)：p表示多少位数，d表示有多少位表示小数
与钱相关，比如工资使用BigDecimal，不用使用float、double避免计算时(二进制计算)的精度丢失
参考：https://www.cnblogs.com/owenma/p/7097602.html
参考：https://juejin.cn/post/7121852516228136996
float、double在存储为二进制时会出现精度丢失，导致进行二进制计算时出现不数据不准确
2. char和varchar
varchar记录的是字符的长度
使用char，由于时固定长度，在数据检索时，磁盘IO的次数要比varchar少(每个数据段需要当前数据段的长度和结束)
所以，在长度变化不大的情况下，使用char。
当varchar大于5000，使用text代替，并且另建一张表，避免影响其它字端的检索效率
参考：https://www.jianshu.com/p/a1aa86e17bf7
3. 对于何时在表建立冗余字段的考虑
4. 业务中不使用select *
- 增加分析器而外的开销
- 网络IO
- 容易出错
分库分表的场景，有些中间件会根据第一张表作为meta数据替代*，这就有可能在DDL发布过程中，部分表有新字段，部分表没有新字段，导致当查询到没有新字段的库表时报错
5.replace into
对于有主键或者唯一键冲突的情况下，replace会使用delete+insert执行。但是在row模式下，binlog记录的是update
因此有这么一种情况：在自增主键并且binlog是row模式，当发生唯一性冲突时，主从库的自增列会产生不一致，导致主从切换时，在新主库新增数据会出现主键冲突（自增列是小于最大id值的）
6.深度分页的解决方案
- limit如何优化
假设有如下表：
create table a (int id, int fr_id, varchar field, pk id, key fr_id)
先来看下面一句sql
select * from table_a order by fr_id limit 10000,100
上面这一段sql存在的问题：
虽让fr_id有索引，查询时可以用到fr_id索引，但是由于查询了所有字段会导致回表，并且随机读严重，扫面更多的页，最终会使整体sql的执行性能不佳
如何优化呢？
使用延迟关联：第一步先利用覆盖索引查询id，再做关联查询
select * from table a inner join (select id from table_a order by fr_id limit 10000,100) as b on a.id = b.id
如何进一步优化？
根据业务场景，如果不需要支持跳页(即只支持翻页，解决深度分页问题)，可以考虑用如下进行优化
第一次查询
select * from fr_id > 0 order by fr_id limt 100
第二次查询
假设第一次查询的结果的最大fr_id为200，那么第二次查询的如下
select * from fr_id > 200 order by fr_id limt 100
使用翻页要考虑的问题时，字段一定要是单调自增的，不然在翻页的过程中会有漏数据
所以整体优化思路为(两种方案二选一)：
1、使用延迟关联，解决两个问题（1.使用覆盖索引 2.减少回表次数、避免随机读，提高性能）
2、根据业务场景，是否需要支持跳页查询？
7.单行大小限制
Mysql在创建表的时候有如下限制：
1、如果单个字段大小大于65535byte，自动转化成text
2、单行大小不能大于65535byte，否则创建失败，不包括text、blob字段
同时在插入数据有如下限制：
限制单行的大小不能大于单行的字段个数*768byte，否则会出现行裂变（768的含义是：mysql会对存储大字段进行优化，对每个字段的前768byte存储在当前页，其余存储在溢出页中，保证一个数据页至少能存储两行数据）
https://blog.csdn.net/wwd0501/article/details/115384399
https://blog.csdn.net/weixin_39761880/article/details/113336491
