随着业务体量和逻辑复杂度的减少，workcenter 对接口的性能耗时有了新的要求，而晋升接口性能最无效的办法当然 对数据库操作逻辑和 SQL 语句进行优化了。本篇分享一些数据库性能优化的教训和倡议
数据库构造优化
mysql 逻辑架构图：
- 第一层：客户端通过连贯服务，将要执行的 sql 指令传输过去
- 第二层：服务器解析并优化 sql，生成最终的执行打算并执行
- 第三层：存储引擎，负责数据库的存储和提取
索引优化
索引蕴含一个或多个列的值。MySql 只能高效的利用索引的最左前缀列。索引的劣势在于：
- 缩小查问扫描的数据量
- 防止排序和零时表
- 将随机 IO 变为程序 IO（程序 IO 的效率高于随机 IO）
优化倡议：
（1）针对特地长的字符串，能够应用前缀索引，依据索引的选择性抉择适合的前缀长度
（2）应用多列索引的时候，能够通过 AND 和 OR 语法连贯
（3）索引在 where 条件查问和 group by 语法查问的时候特地无效
（4）将范畴查问放在条件查问的最初，避免范畴查问导致的左边索引生效的问题
（5）索引最好不要抉择过长的字符串，而且索引列也不宜为 null
SQL 查问优化
查问品质的三个重要指标：（1）响应工夫（服务工夫、排队工夫）、（2）扫码的行、（3）返回的行
优化倡议：
（1）防止查问无关的列，如应用 Select * 返回所有的列表
（2）防止查问无关的行
（3）切分查问。将一个对服务器压力较大的工作，合成到一个较长的工夫中，并分屡次执行。如要删除一万条数据，能够分 10 次执行，每次执行实现后暂停一段时间，再继续执行。过程中能够开释服务器资源给其余工作
（4）合成关联查问。将多表关联查问的一次查问，分解成对单表的屡次查问。能够缩小锁竞争，查问自身的查问效率也比拟高。因为 MySql 的连贯和断开都是轻量级的操作，不会因为查问拆分为屡次，造成效率问题
（5）留神 count 的操作只能统计不为 null 的列，所以统计总的行数应用 count (*)
（6）group by 依照标识列分组效率高，分组后果 不宜呈现分组列之外的列
（7）关联查问提早关联，能够依据查问条件先放大各自要查问的范畴，再关联
（8）Limit 分页优化。能够依据索引笼罩扫码，再依据索引列关联本身查问其余列
（9）Union 查问默认去重，如果不是业务必须，倡议应用效率更好的 Union All
TypeORM 性能优化
WorkCenter 采纳了 TypeORM 作为数据库操作的工具，诚然