尽量避免select * from，仅返回所需字段
在日常查询表数据时，经常不自觉的写select * from，查询全部字段信息；虽然记录少的单表没啥感觉，但当关联多个表且表体量大时，select * from将返回所有表的字段，会影响查询效率。较好的方式，就是需要什么查什么，仅返回所需字段信息；这也符合开发中的最少知道原则，尽量不去暴露不需要的信息。
避免全量查询，尽量小的控制查询粒度
日常开发环境查询中，可能随手就写了select * from tableA，这样的查询将返回全部记录和全部字段，这样的查询如果误升级到生产环境，查询太慢可能会带来灾难性的后果。全表扫描是一种低效的查询方式，应尽量避免。通过使用索引、合适的过滤条件和JOIN优化，减少全表扫描的情况。所以，在查询时时，习惯性的增加where条件过滤（比如分页、字段过滤、日期区间等），返回尽量小的数据，这将大大提升查询效率。
查询时尽量走索引，最好提前设计好索引
当单表记录数太多时，而且通过非索引字段进行表关联查询时，查询效率很低；此时对关联字段建立索引，将大大提升查询效率。所以，在设计表时，最好就考虑业务场景，对常用来过滤查询或者表关联的字段，建立索引，将对后续查询大有裨益。同时，在查询过程中，也尽量走索引查询，比非索引查询效率高太多了。
尽量避开索引失效的场景
索引虽好，但使用不当，可能起不到想要的效果，这其中就需要重点关注索引失效的情况，并尽量避免之。
索引失效的场景主要有：
- 联合索引不满足最左匹配原则
- 使用select * 查询
- 使用索引列进行表达式运算
- 索引列使用了内置函数
- 错误的使用like模糊查询
- 索引列进行类型隐式转换
- 使用or操作
- 使用>,<,!=等进行索引列比较
- 使用is not null
- 使用not in和not exixts
- 错误的order by 排序
Update时避免全量修改，只修改需要的字段
在修改表记录时，一些随手操作就是updateById(Entity entity)，虽然也能更新成功，但注意sql会发现，他把Entity 的全部字段都更新了一遍，而我们可能仅仅只想修改个状态字段。而后者的只用修改少量字段的效率显然比全量修改要高，更重要的是，能避免其他字段被误修改，导致一些其他问题。
尽量使用数值替代字符串类型
-
节省存储空间：数值通常比字符串类型占用更少的存储空间。在大规模的数据集中，使用数值类型可以显著减少数据库的存储需求，从而提高系统的性能和效率。
-
提升查询性能：在数据库查询时，比较数值类型通常比比较字符串类型更快。因为数值类型可以直接进行比较操作，而字符串类型则需要逐个字符比较
慎重选择“硬删除”重要数据
删除数据很爽，但也很有风险，尤其是误删除了重要数据。删除数据，通常有物理删除（硬删除）、逻辑删除。但无论是哪种删除，都要注意限定条件，不要把数据全删了，不要都得跑路了。
物理删除，可以节省内存空间，同时保证表里只有有效的数据，可读性好。但是物理删除话，数据大概率不会恢复。而逻辑删除的话，虽说更安全一点，但是一定程度污染的表数据，后续每次关联查询，都得记得过滤有效数据。
对于一些有价值的历史数据，是否可以考虑设计历史表，用来转存被删除的历史数据，一方面，可保证的可追溯，同时也保证了原表数据的简洁和有效性。
