mysql 使用规范

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/supingemail/article/details/79228902

好记忆不如烂笔头,能记下点东西,就记下点,有时间拿出来看看,也会发觉不一样的感受。

最近在做一个银行业务,要搞一个业务系统,看到里面的代码,我的头都快爆了,为什么呐,因为里面到处都是一堆一堆的 大SQL 你简直是不可以想象,在互联网发展的今天,这种把业务逻辑和运算都交给数据库引擎的设计,还 tm 存在,哥的内心是崩溃的,尤其这还是一个新系统,哥的后脑勺都在流汗,要是一上线,性能瓶颈一来,我去,估计加班也要加死,所以 sql 的应用显得尤为的重要和迫切!


下面网上一些使用的原则,觉得还不错,可以看看。


一,核心规范

  • 不在数据库做计算,cpu计算务必移至业务层

  • 控制单表数据量,单表记录控制在千万级

  • 控制列数量,字段数控制在20以内

  • 平衡范式与冗余,为提高效率可以牺牲范式设计,冗余数据

  • 拒绝3B(big),大sql,大事务,大批量


二,字段类规范

  • 用好数值类型
    tinyint(1Byte)
    smallint(2Byte)
    mediumint(3Byte)
    int(4Byte)
    bigint(8Byte)
    bad case:int(1)/int(11)

  • 有些字符转化为数字
    用int而不是char(15)存储ip

  • 优先使用enum或set
    例如:`sex` enum (‘F’, ‘M’)

  • 避免使用NULL字段
    NULL字段很难查询优化
    NULL字段的索引需要额外空间
    NULL字段的复合索引无效
    bad case:
    `name` char(32) default null
    `age` int not null
    good case:
    `age` int not null default 0

  • 不在数据库里存图片


三,索引类规范

  • 谨慎合理使用索引
    改善查询、减慢更新
    索引一定不是越多越好(
    能不加就不加,要加的一定得加
    覆盖记录条数过多不适合建索引,例如“性别”

  • 字符字段必须建前缀索引

  • 不在索引做列运算
    bad case:
    select id where age +1 = 10;

  • innodb主键合理使用自增列
    主键建立聚簇索引
    主键不应该被修改
    字符串不应该做主键
    如果不指定主键,innodb会使用唯一且非空值索引代替

  • 不用外键,请由程序保证约束


四,sql类规范

  • sql语句尽可能简单
    一条sql只能在一个cpu运算
    大语句拆小语句,减少锁时间
    一条大sql可以堵死整个库

  • 简单的事务
    事务时间尽可能短
    bad case:
    上传图片事务

  • 避免使用触发器,用户自定义函数,请由程序取而代之

  • 不用select *
    消耗cpu,io,内存,带宽
    这种程序不具有扩展性

  • OR改写为IN()

  • OR改写为UNION

话外音:最新的mysql内核已经进行了相关优化

  • limit高效分页
    limit越大,效率越低
    select id from t limit 10000, 10;
    应该改为 =>
    select id from t where id > 10000 limit 10;

  • 使用union all替代union,union有去重开销

  • 尽量不用连接join

  • 务必请使用“同类型”进行比较,否则可能全表扫面

  • 打散批量更新

  • 使用新能分析工具
    show profile;
    mysqlsla;
    mysqldumpslow;
    explain;
    show slow log;
    show processlist;
    show query_response_time(percona)

其实,规则再多,规范再多,那都是大的规范,而不是死的设置。具体业务在使用过程中,还是要根据具体的业务来定。但是总的来说,还是要做到尽量少的把运算,大sql 等都放到数据库层面去,因为数据库的资源是十分宝贵的,但是机器却是可以随时添加的,所以把压力释放出来,放到业务层去处理,而不是去数据库层面。切记切记!

阅读更多
换一批

没有更多推荐了,返回首页