本文转载自微信公众号“小姐姐的味道”，作者小姐姐养的狗。转载本文请联系味觉小姐公众号。晚上，我被叫进宽敞的办公室，主任正在泡茶。高压锅煮着长嘴茶壶，热气缭绕。为首的一抬手，淡黄色的茶水倒了出来，他倒立倒茶叶，两杯茶水漏了出来。“茶？”领导递给我一杯，然后喝了一口。沉默良久，我将监控器转向身边：“最近数据库表里出现了一些有趣的东西，请看一下。”我探出头一看，心沉了下去。时隔五年，在项目中再次见到彪哥和甜甜妹妹，着实让我坐立不安。所谓兄弟表，就是名为gg的数据库表，即public的意思；所谓姊妹字段就是名为mm的表段，也就是密码的意思。与狗屎山相比，这些名字更富想象力，也确实是违规的例子。这样神奇的事情发生过不止一次，任何一个领导者都坐不住了。可惜，开会又开会，讨论某条SQL禁止规定，到头来，便当之门大开，往日的规范承诺统统抛到脑后。数据库命名规范是最基本的规范，连这个都没做好，证明监管工作确实存在漏洞。我连忙拿出手机，翻到xjjdog的文章，打算把数据库要注意的地方汇报给领导。也顺便汇报给大家。我把规范分为六个部分：统一规范、索引规范、SQL规范、命名规范、安全规范、性能小案例。请慢慢听我说。1.统一规范首先，我们来介绍一些通用的规范。这里有大量的经验值。如果你的数据库所在的主机硬件不是很好，可以考虑降低标准。存储引擎：请统一使用innodb存储引擎，专用数据库引擎必须通过DBA的审核。字符集：统一使用utf8字符集。这个要从应用、服务器、数据库表、字段等方面统一。注意：MySQL中的utf8mb4字符集是真正的utf8，请使用这个。适用范围：不要在MySQL中存储大对象，如图片、音乐等；不使用MySQL进行Gis操作和全文检索；不要使用存储过程、触发器、函数和外键，以免破坏数据库的性能和可伸缩性。使用上限：每个MySQL实例，数据库数量不超过50个；单个数据库容量不要超过500GB，否则数据库会被分割；单表记录数不能超过5000W，否则要分表；单个表中的小节数不能超过30个，否则拆分表；单表索引数不超过5个，单个索引字段数不超过5个；varchar字段的最大值不超过1024；注意：VARCHAR(N)中的N表示字符数而不是字节数2。索引规范索引是数据库中一个非常重要的结构，可以加快数据的检索速度。但是索引占用了很多空间。如果你的数据表中的记录很少，就没有必要建立索引。比如小于2000。对于选择性不大的字段（低基数列），不加索引。比如一些状态，类型，布尔判断等等。因为加了也没用。尽量保持索引的内容尽可能短！对于较长的小节，请使用前缀索引。例如：titlevarchar(64)，可以创建前缀索引idx_title(title(16))。合理利用索引最左原则合并相似的索引。比如有三个索引需求（a）（ab）（abc），我们只需要创建abc的索引就可以了。避免对索引列进行计算（这会导致索引失效），如data_format(created_date),substring(short_name,0,6)='xjjdog'。不能使用%前缀模糊查询，因为不能使用索引，例如：WHEREnameLIKE'%flavor'。您不能使用数据库端进行全文搜索操作。虽然支持，但不要这样做。索引的命名要遵循以下规则：idx_前缀表示是普通索引，uk_前缀表示是唯一索引。3.SQL规范建议在每张表中加入以下三个字段。其实SpringBootJPA也建议大家加上这三个字段。根据时间字段，除了审计，还可以做一些非常nice的迁移操作；version字段是高并发下的乐观锁实现，UPDATE语句可以和version字段结合，避免并发操作导致的不一致。created：记录创建时间，时间类型modified：记录修改时间，时间类型version：“乐观锁”版本标记，long类型，默认为0大多数字段应该定义为notnull，并赋予默认值，但不能默认为null，因为数据库无法索引空值。复杂的SQL查询语句是绝对要避免的。我们说的是慢查询。慢查询会占用大量资源并阻塞线程。您应该原谅将大型SQL拆分为多个简单SQL以减少数据锁定时间。另外，不要比较不同数据类型的字段，以免字段类型转换造成性能损失。这就要求我们在SQL语句中传入的参数类型与数据库中定义的类型相同。禁止使用select*进行输出，应选择特定字段进行输出。除了避免无用字段在传输中造成的性能损失外，还可以在一定程度上避免敏感信息的泄露。避免SQL中的now()、rand()、sysdate()、current_user()等结果不确定的函数。禁止使用orderbyrand()。对于插入语句，不要直接使用nsertintotablevalues()，而是添加特定的字段，否则无法适应数据库的变化。做批量插入时，一次可以操作100-200个item，不需要把批号设置成几万。禁止使用非框架业务代码，直接调用setsql_mode或settx_isolation，禁止使用SELECT...FORUPDAT。乐观锁是首选。多表关联不要超过3个，尽量拆分成简单的SQL处理。大多数开发人员会在需要时编写UNION，这通常会导致执行排序以消除重复项。应该尝试使用UNIONALL而不是UNION。请注意对OR语句的一些改进。例如，WHEREid=1ORid=2可以改写为WHEREidIN(1,2)。在不同的领域，OR可以改写为UNIONALL。4.命名标准数据库表和字段命名，不要使用驼峰命名。比如不能叫saleOrder，应该叫sale_order。由于大多数数据库不区分大小写，下划线名称更安全。这些名称只能使用英文小写字母、数字和下划线，长度不超过17个字符。命名应该有确切的含义。和代码规范一样，不允许出现a、b等无意义的字符串。不得使用汉语拼音缩写、中英文混用。严禁出现兄妹场。5.安全securitypicture(1)服务器隔离如果你的公司有多个环境，比如dev环境，test环境等，一定要做好隔离。例如，不允许在线环境直接开发测试，禁止在线数据库压力测试等。这对于避免不必要的数据混淆非常重要。如果条件允许，甚至可以做物理隔离，用不同的IP段来区分。有很多程序员脑子不长，你永远不知道他们连接的是哪个环境的数据库。(2)账户权限决不允许root账户在生产中被远程连接。对于不同的应用，应分配不同的数据库，并建立单独的账户。该帐户可以默认启用选择/插入/更新/删除/执行权限。create不能放过，基本防止程序员删库跑路。对于安全级别高的应用，应该分配读写账户。读账号去掉了各种更新权限，只能做一些sql查询。在账户命名方式上，可以加上_w或_r后缀来表明自己的意图。对于SQL的传入参数（数字、字符、混合使用），必须进行合法性检查，防止SQL注入。商家应提前准备风险SQL语句，集中审核，后果自负。6.性能小的情况下，如果有自增字段，请使用unsigned（无符号）int或bigint。优先使用较小的数据类型，如：数字使用tinyint、smallint、mediumint、int、bigint类型；日期使用日期、日期时间类型；时间使用时间戳，int类型；不要使用char、varchar来存储日期和时间；使用smaller如果可以使用tinyint，则不需要smallint；如果可以使用时间戳，则不需要日期时间；你不能使用tinyblob、mediumblob、blob和longblob。如果表中存在较大的字段类型，则应考虑单独拆分。OLTP数据库绝对要避免大事务和数据库端操作，可以考虑使用NoSQL或大数据计算平台。End可以看到，我们规范中禁止的一些东西，到最后居然都用上了。比如分区表、大字段存储、GIS操作等。但这并不与规范冲突。规范只定义了一些可能造成严重后果的常见操作禁忌，而将风险事项留给专业人士来评估和控制风险点的规模。规范已经制定，必须执行。不管是人工审核还是工具检测。这样系统才能健康成长，程序员不用加班，领导也能开保时捷。这时候，我汇报完了，抬头看着领导。他的头靠在真皮座椅的靠背上，已经沉沉睡去。我轻轻脱下外衣给他披上，拿起茶杯一饮而尽。茶虽然已经凉了，但醇香还在我嘴里萦绕。作者简介：品味小姐姐（xjjdog），一个不允许程序员走弯路的公众号。专注于基础架构和Linux。十年架构，每天百亿流量，与你探讨高并发世界，给你不一样的滋味。我的个人微信xjjdog0，欢迎加好友进一步交流。
