数据库中间件
数据库中间件
Cobar：阿里团队开发，已经多年没有维护更新
MyCat：基于Cobar二次开发，开源社区维护
OneProxy：不开源的商业中间件专注性能和稳定性
KingShard：GO语言开发，在不断完善
Vitess：youtobe生产在使用，不支持MySql原生协议
Atlas：360团队基于MySqlProxy改写，高并发下不稳定
MaxScale：MaxScale是mariadb研发的中间件
MysqlRoute：MySql官方Oracle公司发布的中间件
ShardingJDBC：现在比较主流的中间件
SQL解析>查询优化>SQL路由>SQL改写>SQL执行>结果归并
本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 喵喵鱼塘！
相关推荐
2022-04-10
ShardingJDBC简单介绍
ShardingJDBC介绍 ShardingJDBC是当当网研发的开源分布式数据库中间件，从 3.0 开始Sharding-JDBC被包含在 Sharding-Sphere中，之后该项目进入进入Apache孵化器，4.0版本之后的版本为Apache版本。 ShardingSphere是一套开源的分布式数据库中间件解决方案组成的生态圈，它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar（计划中）这3款相互独立的产品组成。 他们均提供标准化的数据分片、分布式事务和数据库治理功能，可适用于如Java同构、异构语言、容器、云原生等各种多样化的应用场景。 官方地址：https://shardingsphere.apache.org/document/current/cn/overview/ 它定位为轻量级Java框架，在Java的JDBC层提供的额外服务。它使用客户端直连数据库，以jar包形式提供服务，无需额外部署和依赖，可理解为增强版的JDBC驱动，完全兼容JDBC和各种ORM框架 在 maven 的工程里面，我们使用它的方式是引入依赖，然...
2022-04-17
mycat简单介绍
MyCat介绍 如今随着互联网的发展，数据的量级也是成指数式的增长，从GB到TB到PB。对数据的各种操作也是愈加的困难，传统的关系性数据库已经无法满足快速查询与插入数据的需求,这个时候NoSQL的出现暂时解决了这一危机。它通过降低数据的安全性，减少对事务的支持，减少对复杂查询的支持，来获取性能上的提升。但是，在有些场合NoSQL一些折衷是无法满足使用场景的，就比如有些使用场景是绝对要有事务与安全指标的。这个时候NoSQL肯定是无法满足的，所以还是需要使用关系性数据库。如何使用关系型数据库解决海量存储的问题呢？此时就需要做数据库集群，为了提高查询性能将一个数据库的数据分散到不同的数据库中存储，为应对此问题就出现了——MyCat 。 MyCAT的目标是：低成本的将现有的单机数据库和应用平滑迁移到”云”端，解决海量数据存储和业务规模迅速增长情况下的数据存储和访问的瓶颈问题 。 Mycat 背后是阿里曾经开源的知名产品——Cobar，Cobar 的核心功能和优势是 MySQL 数据库分片 相对于cobar的优势 对 cobar 的代码进行了彻底的重构，Mycat在I/O方面...
2022-04-23
mysql创建定时任务
需求：定时删除三个月之前的数据 1.编写需要执行的sql语句 123456789101112## 因为表数据过大（大约2亿数据），需要先查询三个月之前的id节点，增加查询速度select MAX(id) from other_log_info where DATE_FORMAT(createtime,'%Y-%m-%d') = DATE_SUB(CURDATE(),INTERVAL 3 MONTH);## 查询的sql一次不能删除太多数据，防止锁表select * from other_log_info where id < (select MAX(id) from other_log_info where DATE_FORMAT(createtime,'%Y-%m-%d') = DATE_SUB(CURDATE(),INTERVAL 3 MONTH)) LIMIT 0,1000## 由于delete不能直接删除子查询表中的数据，必须用过嵌套一层的方式来解决## 第二种执行方式，如果对于sql比较熟悉，可以用存储过程的"...
2025-08-20
MySQL性能优化全攻略：从入门到精通
基于《MYSQL四十五讲》的核心内容，本文将从基础架构到高级优化，为你呈现一套完整的MySQL性能优化方案。无论你是开发人员还是DBA，都能从中找到实用的优化技巧和最佳实践。 🎯 MySQL性能优化概述为什么要优化MySQL？在高并发的互联网应用中，数据库往往是整个系统的性能瓶颈。根据统计，80%的性能问题都与数据库相关： 查询响应慢: 用户体验下降，业务受影响 并发能力不足: 高峰期系统崩溃 资源消耗大: CPU、内存、磁盘IO压力大 扩展性差: 无法应对业务快速增长 优化原则1. 全面考虑原则12345-- 错误示例：只关注单个查询SELECT * FROM users WHERE age > 18;-- 正确做法：考虑索引、执行计划、系统资源EXPLAIN SELECT * FROM users WHERE age > 18; 2. 数据驱动原则 量化指标: 使用具体的性能指标衡量优化效果 对比测试: A/B测试验证优化方案 持续监控: 建立完善的监控体系 3. 权衡取舍原则 存储 vs 查询: 数据冗余换取查询性能 实时 vs 批量: ...
2022-04-10
分库分表思想
随着单库中的数据量越来越大、数据库的查询QPS越来越高，相应的，对数据库的读写所需要的时间也越来越多。数据库的读写性能可能会成为业务发展的瓶颈。对应的，就需要做数据库性能方面的优化。 场景一：如果数据库的查询QPS【连接数】过高，就需要考虑拆库，通过分库来分担单个数据库的连接压力。比如，如果查询QPS为3500，假设单库可以支撑1000个QPS的话，那么就可以考虑拆分成4个库，来分散查询连接压力。 场景二：如果单表数据量过大，就需要考虑分表，当数据量超过一定量级后，无论是对于数据查询还是数据更新，在经过索引优化等纯数据库层面的传统优化手段之后，还是可能存在性能问题。这是量变产生了质变，这时候就需要去换个思路来解决问题，比如：从数据生产源头、数据处理源头来解决问题，既然数据量很大，那我们就来个分而治之，化整为零。这就产生了分表，把数据按照一定的规则拆分成多张表，来解决单表环境下无法解决的存取性能问题。 场景三：如果单数据库宕机，可能所有数据都会丢失，就需要考虑数据拆分 单库部署情况下，如果数据库宕机，那么故障影响就是100%，而且恢复可能耗时很长。 如果我们拆分成2个库，分别...
2025-06-08
MySQL高性能优化全攻略：从建表设计到查询优化的最佳实践
MySQL作为最流行的关系型数据库，其性能优化是后端开发的核心技能。本文从建表设计到查询优化的全方位视角，为你打造MySQL高性能优化全攻略。 🏗️ 建表设计优化1. 数据类型优化🎯 选择合适的数据类型123456789101112131415-- ❌ 不推荐：使用大字段存储小数据CREATE TABLE user_old ( id BIGINT PRIMARY KEY, age VARCHAR(100), -- 浪费空间 status VARCHAR(50), -- 浪费空间 score DECIMAL(10,8) -- 精度过高);-- ✅ 推荐：精确匹配数据类型CREATE TABLE user_optimized ( id BIGINT PRIMARY KEY, age TINYINT UNSIGNED, -- 0-255足够 status ENUM('active', 'inactive', 'banned'), -- 节...
