网页开发公司网站,seo外包 杭州,西宁做网站君博推荐,wordpress柒比贰MySQL 性能优化
数据库命名规范
所有数据库对象名称必须使用小写字母并用下划线分割所有数据库对象名称禁止使用 MySQL 保留关键字#xff08;如果表名中包含关键字查询时#xff0c;需要将其用单引号括起来#xff09;数据库对象的命名要能做到见名识意#xff0c;并且最…MySQL 性能优化
数据库命名规范
所有数据库对象名称必须使用小写字母并用下划线分割所有数据库对象名称禁止使用 MySQL 保留关键字如果表名中包含关键字查询时需要将其用单引号括起来数据库对象的命名要能做到见名识意并且最后不要超过 32 个字符临时库表必须以 tmp_ 为前缀并以日期为后缀备份表必须以 bak_ 为前缀并以日期 (时间戳) 为后缀所有存储相同数据的列名和列类型必须一致一般作为关联列如果查询时关联列类型不一致会自动进行数据类型隐式转换会造成列上的索引失效导致查询效率降低
数据库基本设计规范
所有表必须使用 InnoDB 存储引擎
没有特殊要求即 InnoDB 无法满足的功能如列存储存储空间数据等的情况下所有表必须使用 InnoDB 存储引擎MySQL5.5 之前默认使用 Myisam5.6 以后默认的为 InnoDB。
InnoDB 支持事务支持行级锁更好的恢复性高并发下性能更好。
数据库和表的字符集统一使用 UTF8
兼容性更好统一字符集可以避免由于字符集转换产生的乱码不同的字符集进行比较前需要进行转换会造成索引失效如果数据库中有存储 emoji 表情的需要字符集需要采用 utf8mb4 字符集。
所有表和字段都需要添加注释
使用 comment 从句添加表和列的备注从一开始就进行数据字典的维护
尽量控制单表数据量的大小建议控制在 500 万以内
500 万并不是 MySQL 数据库的限制过大会造成修改表结构备份恢复都会有很大的问题。
可以用历史数据归档应用于日志数据分库分表应用于业务数据等手段来控制数据量大小
谨慎使用 MySQL 分区表
分区表在物理上表现为多个文件在逻辑上表现为一个表
谨慎选择分区键跨分区查询效率可能更低
建议采用物理分表的方式管理大数据。
经常一起使用的列放到一个表中
避免更多的关联操作。
禁止在表中建立预留字段
预留字段的命名很难做到见名识义。预留字段无法确认存储的数据类型所以无法选择合适的类型。对预留字段类型的修改会对表进行锁定。
禁止在数据库中存储文件比如图片这类大的二进制数据
在数据库中存储文件会严重影响数据库性能消耗过多存储空间。
文件比如图片这类大的二进制数据通常存储于文件服务器数据库只存储文件地址信息。
不要被数据库范式所束缚
一般来说设计关系数据库时需要满足第三范式但为了满足第三范式我们可能会拆分出多张表。而在进行查询时需要对多张表进行关联查询有时为了提高查询效率会降低范式的要求在表中保存一定的冗余信息也叫做反范式。但要注意反范式一定要适度。
禁止在线上做数据库压力测试
禁止从开发环境,测试环境直接连接生产环境数据库
安全隐患极大要对生产环境抱有敬畏之心
数据库字段设计规范
优先选择符合存储需要的最小的数据类型
存储字节越小占用也就空间越小性能也越好。
a.某些字符串可以转换成数字类型存储比如可以将 IP 地址转换成整型数据。
数字是连续的性能更好占用空间也更小。
MySQL 提供了两个方法来处理 ip 地址
INET_ATON()把 ip 转为无符号整型 (4-8 位)INET_NTOA() :把整型的 ip 转为地址
插入数据前先用 INET_ATON() 把 ip 地址转为整型显示数据时使用 INET_NTOA() 把整型的 ip 地址转为地址显示即可。
b.对于非负型的数据 (如自增 ID,整型 IP年龄) 来说,要优先使用无符号整型来存储。
无符号相对于有符号可以多出一倍的存储空间
SIGNED INT -2147483648~2147483647
UNSIGNED INT 0~4294967295c.小数值类型比如年龄、状态表示如 0/1优先使用 TINYINT 类型。
避免使用 TEXT,BLOB 数据类型最常见的 TEXT 类型可以存储 64k 的数据
a. 建议把 BLOB 或是 TEXT 列分离到单独的扩展表中。
MySQL 内存临时表不支持 TEXT、BLOB 这样的大数据类型如果查询中包含这样的数据在排序等操作时就不能使用内存临时表必须使用磁盘临时表进行。而且对于这种数据MySQL 还是要进行二次查询会使 sql 性能变得很差但是不是说一定不能使用这样的数据类型。
如果一定要使用建议把 BLOB 或是 TEXT 列分离到单独的扩展表中查询时一定不要使用 select *而只需要取出必要的列不需要 TEXT 列的数据时不要对该列进行查询。
2、TEXT 或 BLOB 类型只能使用前缀索引
因为 MySQL 对索引字段长度是有限制的所以 TEXT 类型只能使用前缀索引并且 TEXT 列上是不能有默认值的
避免使用 ENUM 类型
修改 ENUM 值需要使用 ALTER 语句ENUM 类型的 ORDER BY 操作效率低需要额外操作ENUM 数据类型存在一些限制比如建议不要使用数值作为 ENUM 的枚举值。
尽可能把所有列定义为 NOT NULL
除非有特别的原因使用 NULL 值应该总是让字段保持 NOT NULL。
索引 NULL 列需要额外的空间来保存所以要占用更多的空间进行比较和计算时要对 NULL 值做特别的处理。
一定不要用字符串存储日期
对于日期类型来说 一定不要用字符串存储日期。可以考虑 DATETIME、TIMESTAMP 和 数值型时间戳。
同财务相关的金额类数据必须使用 decimal 类型
非精准浮点float,double精准浮点decimal
decimal 类型为精准浮点数在计算时不会丢失精度。占用空间由定义的宽度决定每 4 个字节可以存储 9 位数字并且小数点要占用一个字节。并且decimal 可用于存储比 bigint 更大的整型数据
不过 由于 decimal 需要额外的空间和计算开销应该尽量只在需要对数据进行精确计算时才使用 decimal 。
单表不要包含过多字段
如果一个表包含过多字段的话可以考虑将其分解成多个表必要时增加中间表进行关联。
索引设计规范
限制每张表上的索引数量,建议单张表索引不超过 5 个
索引并不是越多越好索引可以提高效率同样可以降低效率。
索引可以增加查询效率但同样也会降低插入和更新的效率甚至有些情况下会降低查询效率。
因为 MySQL 优化器在选择如何优化查询时会根据统一信息对每一个可以用到的索引来进行评估以生成出一个最好的执行计划如果同时有很多个索引都可以用于查询就会增加 MySQL 优化器生成执行计划的时间同样会降低查询性能。
禁止使用全文索引
全文索引不适用于 OLTP 场景。
禁止给表中的每一列都建立单独的索引
5.6 版本之前一个 sql 只能使用到一个表中的一个索引5.6 以后虽然有了合并索引的优化方式但是还是远远没有使用一个联合索引的查询方式好。
每个 InnoDB 表必须有个主键
InnoDB 是一种索引组织表数据的存储的逻辑顺序和索引的顺序是相同的。每个表都可以有多个索引但是表的存储顺序只能有一种。
InnoDB 是按照主键索引的顺序来组织表的
不要使用更新频繁的列作为主键不使用多列主键相当于联合索引不要使用 UUID,MD5,HASH,字符串列作为主键无法保证数据的顺序增长主键建议使用自增 ID 值
常见索引列建议
出现在 SELECT、UPDATE、DELETE 语句的 WHERE 从句中的列包含在 ORDER BY、GROUP BY、DISTINCT 中的字段并不要将符合 1 和 2 中的字段的列都建立一个索引 通常将 1、2 中的字段建立联合索引效果更好多表 join 的关联列
如何选择索引列的顺序
建立索引的目的是希望通过索引进行数据查找减少随机 IO增加查询性能 索引能过滤出越少的数据则从磁盘中读入的数据也就越少。
区分度最高的放在联合索引的最左侧区分度列中不同值的数量/列的总行数尽量把字段长度小的列放在联合索引的最左侧因为字段长度越小一页能存储的数据量越大IO 性能也就越好使用最频繁的列放到联合索引的左侧这样可以比较少的建立一些索引
避免建立冗余索引和重复索引增加了查询优化器生成执行计划的时间
重复索引示例primary key(id)、index(id)、unique index(id)冗余索引示例index(a,b,c)、index(a,b)、index(a)
对于频繁的查询优先考虑使用覆盖索引 覆盖索引就是包含了所有查询字段 (where,select,order by,group by 包含的字段) 的索引 覆盖索引的好处
避免 InnoDB 表进行索引的二次查询: InnoDB 是以聚集索引的顺序来存储的对于 InnoDB 来说二级索引在叶子节点中所保存的是行的主键信息如果是用二级索引查询数据的话在查找到相应的键值后还要通过主键进行二次查询才能获取我们真实所需要的数据。而在覆盖索引中二级索引的键值中可以获取所有的数据避免了对主键的二次查询 减少了 IO 操作提升了查询效率。可以把随机 IO 变成顺序 IO 加快查询效率: 由于覆盖索引是按键值的顺序存储的对于 IO 密集型的范围查找来说对比随机从磁盘读取每一行的数据 IO 要少的多因此利用覆盖索引在访问时也可以把磁盘的随机读取的 IO 转变成索引查找的顺序 IO。
索引 SET 规范
尽量避免使用外键约束
不建议使用外键约束foreign key但一定要在表与表之间的关联键上建立索引外键可用于保证数据的参照完整性但建议在业务端实现外键会影响父表和子表的写操作从而降低性能
数据库 SQL 开发规范
尽量不在数据库做运算复杂运算需移到业务应用里完成
尽量不在数据库做运算复杂运算需移到业务应用里完成。这样可以避免数据库的负担过重影响数据库的性能和稳定性。数据库的主要作用是存储和管理数据而不是处理数据。
优化对性能影响较大的 SQL 语句
要找到最需要优化的 SQL 语句。要么是使用最频繁的语句要么是优化后提高最明显的语句可以通过查询 MySQL 的慢查询日志来发现需要进行优化的 SQL 语句。
充分利用表上已经存在的索引
避免使用双%号的查询条件。如a like %123%如果无前置%,只有后置%是可以用到列上的索引的
一个 SQL 只能利用到复合索引中的一列进行范围查询。如有 a,b,c 列的联合索引在查询条件中有 a 列的范围查询则在 b,c 列上的索引将不会被用到。
在定义联合索引时如果 a 列要用到范围查找的话就要把 a 列放到联合索引的右侧使用 left join 或 not exists 来优化 not in 操作因为 not in 也通常会使用索引失效。
禁止使用 SELECT * 必须使用 SELECT 字段列表 查询
SELECT * 会消耗更多的 CPU。SELECT * 无用字段增加网络带宽资源消耗增加数据传输时间尤其是大字段如 varchar、blob、text。SELECT * 无法使用 MySQL 优化器覆盖索引的优化基于 MySQL 优化器的“覆盖索引”策略又是速度极快效率极高业界极为推荐的查询优化方式SELECT 字段列表 可减少表结构变更带来的影响、
禁止使用不含字段列表的 INSERT 语句
如
insert into t values (a,b,c);应使用
insert into t(c1,c2,c3) values (a,b,c);建议使用预编译语句进行数据库操作
预编译语句可以重复使用这些计划减少 SQL 编译所需要的时间还可以解决动态 SQL 所带来的 SQL 注入的问题。只传参数比传递 SQL 语句更高效。相同语句可以一次解析多次使用提高处理效率。
避免数据类型的隐式转换
隐式转换会导致索引失效如:
select name,phone from customer where id 111;避免使用子查询可以把子查询优化为 join 操作
通常子查询在 in 子句中且子查询中为简单 SQL(不包含 union、group by、order by、limit 从句) 时,才可以把子查询转化为关联查询进行优化。
子查询性能差的原因 子查询的结果集无法使用索引通常子查询的结果集会被存储到临时表中不论是内存临时表还是磁盘临时表都不会存在索引所以查询性能会受到一定的影响。特别是对于返回结果集比较大的子查询其对查询性能的影响也就越大。由于子查询会产生大量的临时表也没有索引所以会消耗过多的 CPU 和 IO 资源产生大量的慢查询。
避免使用 JOIN 关联太多的表
对于 MySQL 来说是存在关联缓存的缓存的大小可以由 join_buffer_size 参数进行设置。
在 MySQL 中对于同一个 SQL 多关联join一个表就会多分配一个关联缓存如果在一个 SQL 中关联的表越多所占用的内存也就越大。
如果程序中大量的使用了多表关联的操作同时 join_buffer_size 设置的也不合理的情况下就容易造成服务器内存溢出的情况就会影响到服务器数据库性能的稳定性。
同时对于关联操作来说会产生临时表操作影响查询效率MySQL 最多允许关联 61 个表建议不超过 5 个。
减少同数据库的交互次数
数据库更适合处理批量操作合并多个相同的操作到一起可以提高处理效率。
对应同一列进行 or 判断时使用 in 代替 or
in 的值不要超过 500 个in 操作可以更有效的利用索引or 大多数情况下很少能利用到索引。
禁止使用 order by rand() 进行随机排序
order by rand() 会把表中所有符合条件的数据装载到内存中然后在内存中对所有数据根据随机生成的值进行排序并且可能会对每一行都生成一个随机值如果满足条件的数据集非常大就会消耗大量的 CPU 和 IO 及内存资源。
推荐在程序中获取一个随机值然后从数据库中获取数据的方式。
WHERE 从句中禁止对列进行函数转换和计算
对列进行函数转换或计算时会导致无法使用索引
不推荐
where date(create_time)20190101推荐
where create_time 20190101 and create_time 20190102在明显不会有重复值时使用 UNION ALL 而不是 UNION
UNION 会把两个结果集的所有数据放到临时表中后再进行去重操作UNION ALL 不会再对结果集进行去重操作
拆分复杂的大 SQL 为多个小 SQL
大 SQL 逻辑上比较复杂需要占用大量 CPU 进行计算的 SQLMySQL 中一个 SQL 只能使用一个 CPU 进行计算SQL 拆分后可以通过并行执行来提高处理效率
程序连接不同的数据库使用不同的账号禁止跨库查询
为数据库迁移和分库分表留出余地降低业务耦合度避免权限过大而产生的安全风险
数据库操作行为规范
超 100 万行的批量写 (UPDATE,DELETE,INSERT) 操作,要分批多次进行操作
大批量操作可能会造成严重的主从延迟
主从环境中,大批量操作可能会造成严重的主从延迟大批量的写操作一般都需要执行一定长的时间而只有当主库上执行完成后才会在其他从库上执行所以会造成主库与从库长时间的延迟情况
binlog 日志为 row 格式时会产生大量的日志
大批量写操作会产生大量日志特别是对于 row 格式二进制数据而言由于在 row 格式中会记录每一行数据的修改我们一次修改的数据越多产生的日志量也就会越多日志的传输和恢复所需要的时间也就越长这也是造成主从延迟的一个原因
避免产生大事务操作
大批量修改数据一定是在一个事务中进行的这就会造成表中大批量数据进行锁定从而导致大量的阻塞阻塞会对 MySQL 的性能产生非常大的影响。
特别是长时间的阻塞会占满所有数据库的可用连接这会使生产环境中的其他应用无法连接到数据库因此一定要注意大批量写操作要进行分批。
对于大表使用 pt-online-schema-change 修改表结构
避免大表修改产生的主从延迟避免在对表字段进行修改时进行锁表
对大表数据结构的修改一定要谨慎会造成严重的锁表操作尤其是生产环境是不能容忍的。
pt-online-schema-change 它会首先建立一个与原表结构相同的新表并且在新表上进行表结构的修改然后再把原表中的数据复制到新表中并在原表中增加一些触发器。把原表中新增的数据也复制到新表中在行所有数据复制完成之后把新表命名成原表并把原来的表删除掉。把原来一个 DDL 操作分解成多个小的批次进行。
禁止为程序使用的账号赋予 super 权限
当达到最大连接数限制时还运行 1 个有 super 权限的用户连接super 权限只能留给 DBA 处理问题的账号使用
对于程序连接数据库账号,遵循权限最小原则
程序使用数据库账号只能在一个 DB 下使用不准跨库程序使用的账号原则上不准有 drop 权限
读写分离
什么是读写分离
见名思意根据读写分离的名字我们就可以知道读写分离主要是为了将对数据库的读写操作分散到不同的数据库节点上。 这样的话就能够小幅提升写性能大幅提升读性能。
我简单画了一张图来帮助不太清楚读写分离的小伙伴理解。 一般情况下我们都会选择一主多从也就是一台主数据库负责写其他的从数据库负责读。主库和从库之间会进行数据同步以保证从库中数据的准确性。这样的架构实现起来比较简单并且也符合系统的写少读多的特点。
读写分离会带来什么问题如何解决
读写分离对于提升数据库的并发非常有效但是同时也会引来一个问题主库和从库的数据存在延迟比如你写完主库之后主库的数据同步到从库是需要时间的这个时间差就导致了主库和从库的数据不一致性问题。这也就是我们经常说的 主从同步延迟 。
主从同步延迟问题的解决没有特别好的一种方案可能是我太菜了欢迎评论区补充。你可以根据自己的业务场景参考一下下面几种解决办法。
1.强制将读请求路由到主库处理。
既然你从库的数据过期了那我就直接从主库读取嘛这种方案虽然会增加主库的压力但是实现起来比较简单也是我了解到的使用最多的一种方式。
比如 Sharding-JDBC 就是采用的这种方案。通过使用 Sharding-JDBC 的 HintManager 分片键值管理器我们可以强制使用主库。
HintManager hintManager HintManager.getInstance();
hintManager.setMasterRouteOnly();
// 继续JDBC操作对于这种方案你可以将那些必须获取最新数据的读请求都交给主库处理。
2.延迟读取。
还有一些朋友肯定会想既然主从同步存在延迟那我就在延迟之后读取啊比如主从同步延迟 0.5s,那我就 1s 之后再读取数据。这样多方便啊方便是方便但是也很扯淡。
不过如果你是这样设计业务流程就会好很多对于一些对数据比较敏感的场景你可以在完成写请求之后避免立即进行请求操作。比如你支付成功之后跳转到一个支付成功的页面当你点击返回之后才返回自己的账户。
如何实现读写分离
不论是使用哪一种读写分离具体的实现方案想要实现读写分离一般包含如下几步
部署多台数据库选择其中的一台作为主数据库其他的一台或者多台作为从数据库。保证主数据库和从数据库之间的数据是实时同步的这个过程也就是我们常说的主从复制。系统将写请求交给主数据库处理读请求交给从数据库处理。
落实到项目本身的话常用的方式有两种
1. 代理方式 我们可以在应用和数据中间加了一个代理层。应用程序所有的数据请求都交给代理层处理代理层负责分离读写请求将它们路由到对应的数据库中。
提供类似功能的中间件有 MySQL Router官方、Atlas基于 MySQL Proxy、MaxScale、MyCat。
2. 组件方式
在这种方式中我们可以通过引入第三方组件来帮助我们读写请求。
这也是我比较推荐的一种方式。这种方式目前在各种互联网公司中用的最多的相关的实际的案例也非常多。如果你要采用这种方式的话推荐使用 sharding-jdbc 直接引入 jar 包即可使用非常方便。同时也节省了很多运维的成本。
https://shardingsphere.apache.org/document/legacy/3.x/document/cn/manual/sharding-jdbc/usage/read-write-splitting/
主从复制原理是什么
MySQL binlog(binary log 即二进制日志文件) 主要记录了 MySQL 数据库中数据的所有变化(数据库执行的所有 DDL 和 DML 语句)。因此我们根据主库的 MySQL binlog 日志就能够将主库的数据同步到从库中。 MySQL主从复制
主库将数据库中数据的变化写入到 binlog从库连接主库从库会创建一个 I/O 线程向主库请求更新的 binlog主库会创建一个 binlog dump 线程来发送 binlog 从库中的 I/O 线程负责接收从库的 I/O 线程将接收的 binlog 写入到 relay log 中。从库的 SQL 线程读取 relay log 同步数据本地也就是再执行一遍 SQL 。
阿里开源的一个叫做 canal 的工具。这个工具可以帮助我们实现 MySQL 和其他数据源比如 Elasticsearch 或者另外一台 MySQL 数据库之间的数据同步。
http://t.csdnimg.cn/czFvm
分库分表
读写分离主要应对的是数据库读并发没有解决数据库存储问题。试想一下如果 MySQL 一张表的数据量过大怎么办?
什么是分库
分库 就是将数据库中的数据分散到不同的数据库上可以垂直分库也可以水平分库。
垂直分库 就是把单一数据库按照业务进行划分不同的业务使用不同的数据库进而将一个数据库的压力分担到多个数据库。
举个例子说你将数据库中的用户表、订单表和商品表分别单独拆分为用户数据库、订单数据库和商品数据库。 水平分库 是把同一个表按一定规则拆分到不同的数据库中每个库可以位于不同的服务器上这样就实现了水平扩展解决了单表的存储和性能瓶颈的问题。
举个例子订单表数据量太大你对订单表进行了水平切分水平分表然后将切分后的 2 张订单表分别放在两个不同的数据库。
水平分库
什么是分表
分表 就是对单表的数据进行拆分可以是垂直拆分也可以是水平拆分。
垂直分表 是对数据表列的拆分把一张列比较多的表拆分为多张表。
举个例子我们可以将用户信息表中的一些列单独抽出来作为一个表。
水平分表 是对数据表行的拆分把一张行比较多的表拆分为多张表可以解决单一表数据量过大的问题。
举个例子我们可以将用户信息表拆分成多个用户信息表这样就可以避免单一表数据量过大对性能造成影响。
水平拆分只能解决单表数据量大的问题为了提升性能我们通常会选择将拆分后的多张表放在不同的数据库中。也就是说水平分表通常和水平分库同时出现。 什么情况下需要分库分表
遇到下面几种场景可以考虑分库分表
单表的数据达到千万级别以上数据库读写速度比较缓慢。数据库中的数据占用的空间越来越大备份时间越来越长。应用的并发量太大。
常见的分片算法有哪些
分片算法主要解决了数据被水平分片之后数据究竟该存放在哪个表的问题。
哈希分片求指定 key比如 id 的哈希然后根据哈希值确定数据应被放置在哪个表中。哈希分片比较适合随机读写的场景不太适合经常需要范围查询的场景。范围分片按照特性的范围区间比如时间区间、ID 区间来分配数据比如 将 id 为 1~299999 的记录分到第一个库 300000~599999 的分到第二个库。范围分片适合需要经常进行范围查找的场景不太适合随机读写的场景数据未被分散容易出现热点数据的问题。地理位置分片很多 NewSQL 数据库都支持地理位置分片算法也就是根据地理位置如城市、地域来分配数据。融合算法灵活组合多种分片算法比如将哈希分片和范围分片组合。
分库分表会带来什么问题呢
记住你在公司做的任何技术决策不光是要考虑这个技术能不能满足我们的要求是否适合当前业务场景还要重点考虑其带来的成本。
引入分库分表之后会给系统带来什么挑战呢 join 操作同一个数据库中的表分布在了不同的数据库中导致无法使用 join 操作。这样就导致我们需要手动进行数据的封装比如你在一个数据库中查询到一个数据之后再根据这个数据去另外一个数据库中找对应的数据。不过很多大厂的资深 DBA 都是建议尽量不要使用 join 操作。因为 join 的效率低并且会对分库分表造成影响。对于需要用到 join 操作的地方可以采用多次查询业务层进行数据组装的方法。不过这种方法需要考虑业务上多次查询的事务性的容忍度。 事务问题同一个数据库中的表分布在了不同的数据库中如果单个操作涉及到多个数据库那么数据库自带的事务就无法满足我们的要求了。这个时候我们就需要引入分布式事务了。 分布式 ID分库之后 数据遍布在不同服务器上的数据库数据库的自增主键已经没办法满足生成的主键唯一了。我们如何为不同的数据节点生成全局唯一主键呢这个时候我们就需要为我们的系统引入分布式 ID 了。 跨库聚合查询问题分库分表会导致常规聚合查询操作如 group byorder by 等变得异常复杂。这是因为这些操作需要在多个分片上进行数据汇总和排序而不是在单个数据库上进行。为了实现这些操作需要编写复杂的业务代码或者使用中间件来协调分片间的通信和数据传输。这样会增加开发和维护的成本以及影响查询的性能和可扩展性。
另外引入分库分表之后一般需要 DBA 的参与同时还需要更多的数据库服务器这些都属于成本。
分库分表有没有什么比较推荐的方案
Apache ShardingSphere 是一款分布式的数据库生态系统 可以将任意数据库转换为分布式数据库并通过数据分片、弹性伸缩、加密等能力对原有数据库进行增强。
ShardingSphere 项目包括 Sharding-JDBC、Sharding-Proxy 和 Sharding-Sidecar是当当捐入 Apache 的目前主要由京东数科的一些巨佬维护。
ShardingSphere 绝对可以说是当前分库分表的首选ShardingSphere 的功能完善除了支持读写分离和分库分表还提供分布式事务、数据库治理、影子库、数据加密和脱敏等功能。
ShardingSphere 提供的功能如下 ShardingSphere 的优势如下摘自 ShardingSphere 官方文档https://shardingsphere.apache.org/document/current/cn/overview/open in new window
极致性能驱动程序端历经长年打磨效率接近原生 JDBC性能极致。生态兼容代理端支持任何通过 MySQL/PostgreSQL 协议的应用访问驱动程序端可对接任意实现 JDBC 规范的数据库。业务零侵入面对数据库替换场景ShardingSphere 可满足业务无需改造实现平滑业务迁移。运维低成本在保留原技术栈不变前提下对 DBA 学习、管理成本低交互友好。安全稳定基于成熟数据库底座之上提供增量能力兼顾安全性及稳定性。弹性扩展具备计算、存储平滑在线扩展能力可满足业务多变的需求。开放生态通过多层次内核、功能、生态插件化能力为用户提供可定制满足自身特殊需求的独有系统。
分库分表后数据怎么迁移呢
分库分表之后我们如何将老库单库单表的数据迁移到新库分库分表后的数据库系统呢
比较简单同时也是非常常用的方案就是停机迁移写个脚本老库的数据写到新库中。比如你在凌晨 2 点系统使用的人数非常少的时候挂一个公告说系统要维护升级预计 1 小时。然后你写一个脚本将老库的数据都同步到新库中。
如果你不想停机迁移数据的话也可以考虑双写方案。双写方案是针对那种不能停机迁移的场景实现起来要稍微麻烦一些。具体原理是这样的
我们对老库的更新操作增删改同时也要写入新库双写。如果操作的数据不存在于新库的话需要插入到新库中。 这样就能保证咱们新库里的数据是最新的。在迁移过程双写只会让被更新操作过的老库中的数据同步到新库我们还需要自己写脚本将老库中的数据和新库的数据做比对。如果新库中没有那咱们就把数据插入到新库。如果新库有旧库没有就把新库对应的数据删除冗余数据清理。重复上一步的操作直到老库和新库的数据一致为止。
想要在项目中实施双写还是比较麻烦的很容易会出现问题。我们可以借助上面提到的数据库同步工具 Canal 做增量数据迁移还是依赖 binlog开发和维护成本较低
具体使用可以查看若依和芋道都很不错
http://doc.ruoyi.vip/ruoyi-cloud/cloud/sharding.html
https://mp.weixin.qq.com/s/A2MYOFT7SP-7kGOon8qJaw
