以下是其github代码库：https://github.com/Qihoo360/Atlas
本人混迹qq群2年多了，经常听到有人说“数据表太大了，需要分表”，“xxxx了，要分表”的言论，那么，到底为什么要分表？
默认情况下，MongoDB 更侧重高数据写入性能，而非事务安全，MongoDB 很适合业务系统中有大量 “低价值” 数据的场景。但是应当避免在高事务安全性的系统中使用 MongoDB，除非能从架构设计上保证事务安全。
分表 - 从表面意思上看呢，就是把一张表分成N多个小表，每一个小表都是完正的一张表。分表后数据都是存放在分表里，总表只是一个外壳，存取数据发生在一个一个的分表里面。分表后单表的并发能力提高了，磁盘I/O性能也提高了。并发能力为什么提高了呢，因为查寻一次所花的时间变短了，如果出现高并发的话，总表可以根据不同 的查询，将并发压力分到不同的小表里面。
介绍 随着数据量的不断增大，传统的直连数据库对数据进行访问的方式已经无法满足一般公司的需求。通过数据库中间件，可以对数据库进行水平扩展，由原来单台数据库扩展到多台数据库，数据库中间件通过路由规则将数据的访问请求路由到其中一台数据库上，从而大大降低了数据访问的瓶颈和单台数据库的压力。通过数据库中间件还可以将DBA和研发进行解耦，提升DBA运维效率。 奇虎360公司开源的Atlas是优秀的数据库中间件，美团点评DBA团队针对公司内部需求，在其上做了很多改进工作，形成了新的高可靠、高可用企业级数据库中间件DBP
这段时间团队在梳理mysql使用上的一些痛点（分库分表、读写分离、权限控制、监控告警、日志审计等），也调研了业内一些mysql中间件的实现，这里把对问题域的思考，以及常见中间件整理沉淀一下
DM（TiDB Data Migration）是由 PingCAP 开发的一体化数据同步平台，支持从 MySQL 或 MariaDB 到 TiDB 的全量数据迁移和增量数据同步。无论是从 MySQL 向 TiDB 进行平滑数据迁移还是用 TiDB 作为多个 MySQL 实例的数据汇总库，都可以通过 DM 来实现。DM 在 TiDB DevCon 2019 上正式开源，经过半年多时间在大量用户、开发者的支持和反馈下，其功能和稳定性越来越完善。在今天，我们宣布 DM 1.0 GA 正式发布。
Atlas是由 Qihoo 360, Web平台部基础架构团队开发维护的一个基于MySQL协议的数据中间层项目。 它是在mysql-proxy 0.8.2版本的基础上，对其进行了优化，增加了一些新的功能特性; 360内部使用Atlas运行的mysql业务，每天承载的读写请求数达几十亿条;
“增删改查”都是查找问题，因为你都得先找到数据才能对数据做操作。那存储系统性能问题，其实就是查找快慢问题。
内容为慕课网的《高并发 高性能 高可用 Mysql 实战》视频的学习笔记内容和个人整理扩展之后的笔记，这一节讲述三高架构的另外两个部分切换和扩展，扩展指的是分库分表减轻数据库的压力，同时因为分库分表需要针对节点宕机问题引入了一些优化手段，而切换部分就是讲述节点宕机的切换问题的，最后我们结合复制的主从切换讲述如何搭建一个三高的架构。
我们都知道，随着业务量的增长，数据量也会随之增加，这个时候就需要关注业务大表，因为大表会影响查询性能，DDL变更时间很长，影响业务的可用性，同时导致从库延迟很大，如果业务做了读写分离，导致用户重复操作产生脏数据，例如重复下单。
1.高可用分析： 高可用，主库挂了，keepalive（只是一种工具）会自动切换到备库。这个过程对业务层是透明的，无需修改代码或配置。
1、高可用分析：高可用，主库挂了，keepalive（只是一种工具）会自动切换到备库。这个过程对业务层是透明的，无需修改代码或配置。
抛开业务逻辑的因素，根据不同的版本、不同平台、不同停机时间需求，有不同的可选路径决定迁移方
mysq中有一种机制是表锁定和行锁定，是为了保证数据的完整性。表锁定表示你们都不能对这张表进行操作，必须等我对表操作完才行。行锁定也一样，别的sql必须等我对这条数据操作完了，才能对这条数据进行操作。当出现这种情况时，我们可以考虑分表或分区。
注：图中圈出的是数据同步的地方，数据同步（从库从主库拉取binlog日志，再执行一遍）是需要时间的，这个同步时间内主库和从库的数据会存在不一致的情况。如果同步过程中有读请求，那么读到的就是从库中的老数据。如下图。
当 mysql 的一个大表总数达上亿时，mysql 性能变的很差，且新增或修改字段、索引也需要花费很长时间，至少十几个小时。这种情况，一般的做法是分库分表，这种方法需要业务层根据规则，物理分库分表，比如按照时间分表，业务代码需要兼容。Tidb 是分布式 newsql 数据库，兼容了大部分 mysql 协议和操作，业务不需要调整，数据库性能也能保证。
文章集中整理总结mysql分库分表开源产品，分布式数据库的设计，以及实际应用案例等相关内容，部分附上本文作者实际应用过程中的理解。
本文包含数据库架构原则、常见的四种架构方案、两种一致性解决方案、以及作者个人的一些见解。
1、高可用分析：高可用，主库挂了，keepalive（只是一种工具）会自动切换到备库。这个过程对业务层是透明的，无需修改代码或配置。 2、高性能分析：读写都操作主库，很容易产生瓶颈。大部分互联网应用读多写少，读会先成为瓶颈，进而影响写性能。另外，备库只是单纯的备份，资源利用率50%，这点方案二可解决。 3、一致性分析：读写都操作主库，不存在数据一致性问题。 4、扩展性分析：无法通过加从库来扩展读性能，进而提高整体性能。 5、可落地分析：两点影响落地使用。第一，性能一般，这点可以通过建立高效的索引和引入缓存来增加读性能，进而提高性能。这也是通用的方案。第二，扩展性差，这点可以通过分库分表来扩展。
关系型数据库的事务特性可以帮我们解决很多难题，比如数据的一致性问题，所以常规业务持久化存储都会mysql 来兜底。但mysql 的性能是有限的。当业务规模发展到上百万用户，访问量达到上万QPS时，单台mysql实例很难应付。
ShardingCore 是一个支持efcore 2.x 3.x 5.x的一个对于数据库分表的一个简易扩展,当然也支持不分表的普通使用,.Net下并没有类似mycat或者sharding-jdbc之类的开源组件或者说有但是并没有非常适用的或者说个人在用过后有一些地方因为限制没法很好使用所以决定自己开发这个库,目前该库暂未支持分库(未来会支持),仅支持分表,该项目的理念是让你可以已最少的代码量来实现自动分表的实现,经过多个开源项目的摸索参考目前正式开源本项目 项目地址 github 喜欢的朋友可以点下star Thanks♪(･ω･)ﾉ
schema.xml作为Mycat中最重要的配置文件之一，涵盖了Mycat的逻辑库、逻辑表、分片规则、分片节点即数据源的配置。主要包括一下三组标签
1、自动增长字段： 自动增长型字段允许我们在向数据库添加数据时，不考虑主键的取值，记录插入后，数据库系统会自动为其分配一个值，确保绝对不会出现重复。这是我们设置主键的首选：
传统的将数据集中存储至单一数据节点的解决方案，在容量、性能、可用性和运维成本这三方面难满足海量数据场景。在单库单表数据量超过一定容量水位的情况下，索引树层级增加，磁盘I/O也很可能出现压力，会导致很多问题。
用户分析系统以用户的心跳数据为依据，统计查询用户的各种情况。心跳数据很多，经过去重，去无效，数据量还是在2亿/月的水平。普通的查询在这个量级的数据库上根本查不出来，为此，分表分库、优化查询、多线程查询就很有必要了。
众所周知，数据库很容易成为应用系统的瓶颈。单机数据库的资源和处理能力有限，在高并发的分布式系统中，可采用分库分表突破单机局限。本文总结了分库分表的相关概念、全局ID的生成策略、分片策略、平滑扩容方案、以及流行的方案。
本文中的问题精选自上期【你问我答】——数据库专题中读者的提问。【你问我答】是由美团点评技术团队推出的线上问答服务，你在工作学习中遇到的各种技术问题，都可以通过我们微信公众号发问，我们5000+工程师会义务为你解答，欢迎大家踊跃提问。高质量、定义清晰的问题会优先获得解答。 Q1：能不能推荐几本关于SQL的书籍。谢谢！谢谢！ A：推荐图灵出的《SQL必知必会（第4版）》，这也是Amazon上最畅销的SQL图书的中文版，写得很明快，概念非常清楚。这本书用来学习关系型数据库也很不错，至少基本概念比大部头的教材说得
Atlas是由 Qihoo 360公司Web平台部基础架构团队开发维护的一个基于MySQL协议的数据中间层项目。它在MySQL官方推出的MySQL-Proxy 0.8.2版本的基础上，修改了大量bug，添加了很多功能特性。目前该项目在360公司内部得到了广泛应用，很多MySQL业务已经接入了Atlas平台，每天承载的读写请求数达几十亿条。
传统的将数据集中存储至单一数据节点的解决方案，在容量、性能、可用性和运维成本这三方面难于满足海量数据场景。在单库单表数据量超过一定容量水位的情况下，索引树层级增加，磁盘 IO 也很可能出现压力，会导致很多问题。
MySQL近两年一直稳居第二，随时有可能超过Oracle计晋升为第一名，因为MySQL的性能一直在被优化，同时安全机制也是逐渐成熟，更重要的是开源免费的。
上一篇文章《ShardingJdbc分库分表实战案例解析（上）》中我们初步介绍了使用ShardingJdbc实现订单数据分散存储的分库分表方法，在本篇文章中将重点介绍在不停服的情况下实现数据分片存储的在线扩容。具体将以如下两个常见的场景进行演示：1)、尚未进行分库分表的单库单表系统如何平稳的实施分库分表方案；2)、已经实施过分库分表方案的系统，由于数据量的持续增长导致原有分库分表不够用了，需要二次扩容的情况。
http://mini.eastday.com/mobile/170809003639242.html
作者：王克锋 出处：https://kefeng.wang/2018/07/22/mysql-sharding/ 众所周知，数据库很容易成为应用系统的瓶颈。单机数据库的资源和处理能力有限，在高并发的分布式系统中，可采用分库分表突破单机局限。本文总结了分库分表的相关概念、全局ID的生成策略、分片策略、平滑扩容方案、以及流行的方案。 1 分库分表概述 在业务量不大时，单库单表即可支撑。当数据量过大存储不下、或者并发量过大负荷不起时，就要考虑分库分表。 1.1 分库分表相关术语 读写分离: 不同的数据库，同步相同
myisam引擎是5.1版本之前的默认引擎，支持全文检索、压缩、空间函数等，但是不支持事务和行级锁，所以一般用于有大量查询少量插入的场景来使用，而且myisam不支持外键，并且索引和数据是分开存储的。
众所周知，数据库很容易成为应用系统的瓶颈。单机数据库的资源和处理能力有限，在高并发的分布式系统中，可采用分库分表突破单机局限。
关键词：分库分表，路由机制，跨区查询，MySQL 数据变更，分表数据查询管理器与线程技术的结合，Cache
欢迎访问原文: 【MySQL性能优化】MySQL分库分表与水平分割取模案例(三)
res = mysql_query( 'select * from order where date < = $curDate'); 原因： 释放了数据库的CPU 多次调用，传入的SQL相同，才可以利用查询缓存 （11）强制类型转换会全表扫描 select * from user where phone=13800001234 你以为会命中phone索引么？大错特错了，这个语句究竟要怎么改？ 末了，再加一条，不要使用select *（潜台词，文章的SQL都不合格 =_=），只返回需要的列，能够大大的节省数据传输量，与数据库的内存使用量哟。 整理自：https://cloud.tencent.com/developer/article/1054203
社会数字化、智能化的发展进程中，海量的数据带来巨大挑战，各行各业都在加速数字化转型，越来越多的企业意识到数据基础设施是成功的关键。然而，作为数据基础设施的核心，传统数据库例如 MySQL 面临性能和容量瓶颈，通过中间件实现的分库分表方案复杂度高，同时带来高昂的运维成本。
在对诸如订单、交易、支付等实时在线业务系统的研发、维护过程中，随着业务量的快速增长，我们经常会遇到由于关系型数据库（如:MySql）单表数据量增长过大而引发的线上事故；虽然这些事故多数时候是由于不合理的慢SQL而引起的系统雪崩，但有时也会出现由于数据库热点块IO争用而引发的系统性性能下降。总之，单表数据量的无限增长总是会在这样或那样的情况下增加系统的不稳定性因素。
所谓的性能优化，一般针对的是MySQL查询的优化。既然是优化查询，我们自然要先知道查询操作要经过哪些环节，然后思考可以在哪些环节进行优化。
核心篇 数据存储 MySQL 索引使用的注意事项 1.索引不会包含有NULL的列 只要列中包含有NULL值，都将不会被包含在索引中，复合索引中只要有一列含有NULL值，那么这一列对于此符合索引就是无效的。 2.使用短索引 对串列进行索引，如果可以就应该指定一个前缀长度。例如，如果有一个char（255）的列，如果在前10个或20个字符内，多数值是唯一的，那么就不要对整个列进行索引。短索引不仅可以提高查询速度而且可以节省磁盘空间和I/O操作。 3.索引列排序 mysql查询只使用一个索
MySQL 分表3种方法 摘要： 当一张的数据达到几百万时，你查询一次所花的时间会变多，如果有联合查询的话，我想有可能会卡在那儿了，那么分表的目的就在于此，减小数据库的负担，缩短查询时间。 一，先说一下为什么要分表 当一张的数据达到几百万时，你查询一次所花的时间会变多，如果有联合查询的话，我想有可能会死在那儿了。分表的目的就在于此，减小数据库的负担，缩短查询时间。 根据个人经验，mysql执行一个sql的过程如下： 1、接收到sql； 2、把sql放到排队队列中 ； 3、执行sql； 4、返回执行结果。
SQL标准在数据存储的物理方面没有提供太多的指南。SQL语言的使用独立于它所使用的任何数据结构或图表、表、行或列下的介质。但是，大部分高级数据库管理系统已经开发了一些根据文件系统、硬件或者这两者来确定将要用于存储特定数据块物理位置的方法。在MySQL中，InnoDB存储引擎长期支持表空间的概念，并且MySQL服务器甚至在分区引入之前，就能配置为存储不同的数据库使用不同的物理路径(关于如何配置的解释，请参见7.6.1节，“使用符号链接”)。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
