mysql性能优化

2021-04-05

字数：831字 | 预计阅读时长：2分钟

background知识、性能优化

MyISAM 与 InnoDB
- InnoDB 支持事务、能回滚，MyISAM 不支持
- MyISAM 适合查询以及插入为主的应用，修改多或者要安全则innodb
- InnoDB 中必须包含只有自增长字段的索引，MyISAM可以和其他字段一起建立联合索引
- 清空整个表时，InnoDB 是一行一行的删除，效率非常慢。MyISAM 则会重建表
- InnoDB 支持外键，MyISAM 不支持
  - 外键
    - 定义外键约束，关系数据库可以保证无法插入无效的数据
    - 可以把数据与另一张表关联起来，这种列称为外键
    - 外键约束会降低数据库的性能，追求速度并不设置外键约束
多对多关系：通过一个中间表，关联两个一对多关系

分库分表
- 原因
  - 单表数据大，sql效率低
  - 并发高，单库撑不住；磁盘使用高
- 分表
  - 经常读取和不经常读取的字段分开
  - 把一个大的用户表分拆为用户基本信息表user_info和用户详细信息表user_profiles。大部分时候，只需要查询user_info表，提高了查询速度。
- 中间件：proxy方案 or client层方案 sharding-jdbc mycat

crud
分布式id生成

垂直、水平拆分
中间件解决对某个字段值的自动路由，路由到相应的库、表
range、hash
迁移方案
数据库中间件的调研学习、设计分库分表方案、测试环境分库代码的正常读写
开始迁移：
1部署分库策略 2双写 3导数的时候，判断最后修改时间，确保只能新数据覆盖老数据 4自动校验，反复读写，直到新旧库数据一致 5停掉老库，部署分库分表的代码

动态扩容缩容分库分表
一般都够用：32库，每个库1500个写并发，qps可以承受4.8w。加上一个MQ削峰，qps接受8w，每秒消费5w。一个库32张表，1024表，每个表500w，一个mysql放50亿条数据。

1确定机器数量、每台机器多少个库、多少表 2路由规则 3机器上装好mysql 4导数工具导数 5修改配置调整数据库服务器地址 6重发系统上线

分库分表后的全局id
1并发不高，qps几百–直接往一个库写入，获得自增的id；起一个服务，专门地获取最大的id，返回一批新的id
2sequence+固定步长
3uuid –不具有有序性，b+树过多随机读写
4系统时间 + 业务数据
5雪花算法
第一个bit是0。41bit-时间，10bit是工作机器id，12bits序列号
同一ms内有12bits可表达的id
mysql读写分离
Case1在binlog没有被从拉到本地的中继日志中、串行地执行relaylog中的命令时，master宕机
Solution半同步，至少一个从返回ack才认为写操作完成。
Case2由于串行重发，会有延迟几十到百毫秒不等
Solution2并行同步，从开启多线程，并行重放日志，库级别并行
mysql中查看延迟，严重解决：
分库、并行复制、新插入的数据查询不到时处理、查询直连主库
单库单表和分库分表的join

本文作者： yuqing wang
本文链接： https://satyrswang.github.io/2021/04/05/mysql性能优化/
版权声明： 本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。转载请注明出处！

缺失模块。
1、请确保node版本大于6.2
2、在博客根目录（注意不是yilia根目录）执行以下命令：
npm i hexo-generator-json-content --save

3、在根目录_config.yml里添加配置：

  jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

关心算法、cs、网络、投资, 闲听历史、看史评 wechat satyrsh