前言
在数据库中，有很多开发规则。应尽量避免在数据库中过度使用数据库的功能。过度使用会导致数据库慢，再加上数据库是很难扩展的。过多的逻辑在数据库中处理，以后分库、分表比较难处理。当然对于简单的应用，无需有这么多的规则。以下规则，都是大部分是高并发环境下的规则。
对于所有应用，建议规则
1）数据库不存储大文件、图片。
有些人很喜欢在数据库中存储整个文件、图片的base64，这样只会加大数据库的压力。一般只存储路径、url即可。
2）表、字段、数据库用英文、拼音。
在代码规范中，我们都建议使用英文，甚至拼音。使用中文显得很落后。所以在数据库中必须也如此。使用中文，在数据库中可能发生乱码等意想不到的问题。
3）尽量使用Join方式替换子查询
因为子查询会导致性能低下。例如在Mysql中，子查询明显是比Join慢的，子查询需要创建临时表。
4）Join联表查询条件尽量使用索引
Join查询太消耗数据库性能，使用索引的条件能大大增加查询效率。
5）能使用索引的地方使用索引，不能使用索引的地方不使用索引
对于字段值多相同的，尽量避免使用索引。这样没达到你的目的，反而增加数据库的压力。因为插入数据时会变慢，并且索引占用空间。
并不是索引越多越好，反而会导致数据库的压力过大。
对于经常使用作为查询条件，并且是重复率不高的字段，尽量使用索引，大大提升查询效率。
6）避免数据类型的隐形转换而导致的性能底下
在表中的类型，与查询的类型不一致，会导致查询性能底下，甚至是全部查询。但是有些数据库的类型查询语句是非常严格的，例如Postgresql。
例如user表，在数据库中的telphone是字符串类型，而查询时使用select telphone from user where telphone=0208653266
正确是使用select telphone from user where telphone='0208653266'
7）避免错误使用查询条件导致的全表扫描
a. NOT、!=、<>、!<、!>、NOT IN、NOT LIKE等，这些负向查询条件会导致全表扫描
b. %开头的模糊查询，会导致全表扫描
c. 避免数据库中
8）尽量避免数表字段值可以为null
表字段中设有默认值，并且可不为空。否则可能会导致全表扫描。
例如select id from t where num is null 可以在num上设置默认值0，确保表中num列没有null值，然后这样查询： select id from t where num=0
9）不使用查询时select *号
用具体的字段代替*号查询，而不用select * from t。因为会消耗数据库的IO性能、不能有效的利用覆盖索引。
10）不在WHERE条件的属性上使用函数或者表达式
SELECT id FROM t WHERE from date(day)>='2019-03-15' 会导致全表扫描。
正确的写法是：SELECT id FROM t WHERE day>= date('2019-03-15 00:00:00')
11）单表字段数建议小于30，单实例表数据建议小于500
过多的字段、表会导致数据库性能低下，并且难规范难控制。
12）Mysql单表数据尽量控制在500万以内
在mysql过大的数据会造成表修改结构，查询操作性能底下，而这个临界值最好控制在500万。
对于高并发应用，建议规则
1）一个表中，索引数量尽量控制在3个以内，最多不能超过5个。
索引不是越多越好，越多的索引导致数据库压力越大。合适合量地使用索引。
2）规避与合适地使用Join
有时候，在程序中处理Join比数据库中处理更快。
3）禁止使用外键，如果有外键完整性约束，需要应用程序控制
外键会导致表与表之间耦合，update与delete操作都会涉及相关联的表，十分影响sql 的性能，甚至会造成死锁。高并发情况下容易造成数据库性能，大数据高并发业务场景数据库使用以性能优先。
4）尽量不要用自增长主键
不用自增长主键是因为当插入数据时，数据库首先会查询最大的索引值，然后再进行插入操作。所以，使用较短的string类型或者guid直接插入。
5）避免使用外键，如果有外键完整性约束，需要应用程序控制
外键会导致表与表之间耦合，update与delete操作都会涉及相关联的表，十分影响sql 的性能，甚至会造成死锁。高并发情况下容易造成数据库性能，大数据高并发业务场景数据库使用以性能优先。
6）避免使用存储过程、视图、触发器、Event
使用存储过程等，在高并发场景下，数据库很容易CPU过高而崩毁。建议建立把耗CPU的移动到应用程序端，来达到更好扩展、控制的目的。
后续有遇到问题与建议时，慢慢加上其它的规则...
可以关注本人的公众号，多年经验的原创文章共享给大家。
