daobuxinzi的博客

分布式数据库其实没有一个官方的定义，只是我们技术人员提出的一个约定俗成的说法。在数据库领域，当产品不断演进逐渐被大家认识和认可后，就会成了一个标准，比如说微软的 SQL Server 数据库，其他数据库都喜欢拿它作为对比，那 SQL Server 数据库就会成为一个标准。但是分布式数据库也是最近几年才被大家提出，还是比较新的，也没有参照。不过我们可以通过这些大厂大牛们总结的经验来认识分布式数据库。分布式数据库就是用分布式架构实现的数据库。

还是拿前面的例子来说，假如小公司的全栈工程师有点异常情况（请假、跑路、忙不过来等等）老板会考虑招多个这样的人，这就形成了一个集群，好处就是能干更多的活（负载分流）和互补（高可用），但本质上还是一个人做所有事。最常见的数据库就是每个人都用过的 Excel 文档，一个文件可以看成一个数据库，每个 sheet 就是数据表，表里的列就是字段，每一行就是存储的数据。项目开发中的“分布式。对于数据库系统来说，可靠性的最好情况就是服务永不停机，但这是不可能实现的，因为本身硬件层面就存在一定的故障率。

在数据库中，schema（发音 “skee-muh” 或者“skee-mah”，中文模式）是数据库的组织和结构，在这里，产品是电影，所以它包含电影标题，类别，演员等数据。（4）Views(视图)：关于用于评估的数据的特别观点，所以通过这些模式图，我们可以进一步创建一个数据库，它显示了三个表，以及它们的数据类型，表之间的关系，以及它们的主键和外键。从概念上讲，模式是一组相互关联的数据库对象，例如表，表列，列的数据类型，索引，外键等。因此，根据您使用的RDBMS，模式和数据库可能是也可能不是同一个东西。

中表示的是数据库对象集合，它包含了各种对像，比如：表，视图，存储过程，索引等等。一般一个用户对应一个集合，所以为区分不同集合就需给不同集合起名。用户的schema名就相当于用户名，并作为该用户缺省schema。在不同的数据库中要创建的Schema方法是不一样的，但是它们有一个共同的特点就是都支持CREATE SCHEMA语句。例如当我们访问一个数据表时，若该表没有指明属于哪个schema，系统就会自动加上缺省的schema。数据库中，我们可以通过CREATE SCHEMA语句来创建一个数据库。

explain select * from user where name = 'zhangsan' and age = 20 and pos = 'cxy' and phone = '18730658760'; 和索引顺序无关，MySQL底层的优化器会进行优化，调整索引的顺序explain select * from user where name = 'zhangsan' and age = 20 and pos = 'cx

的基础概念做了简单梳理，快速的搭建了一个分库分表案例，但这只是实践分库分表的第一步，下一篇我们会详细的介绍四种分片策略的具体用法和使用场景（必知必会），后边将陆续讲解自定义分布式主键、分布式数据库事务、分布式服务治理，数据脱敏等。但有些时候我们并没有使用任何的分片键和分片策略，可还想将 SQL 路由到目标数据库和表，就需要通过手动干预指定SQL的目标数据库和表信息，这也叫强制路由。如果后去需要增加分片表的数量，要逐一修改分片表的步长，运维成本非常高，所以不建议这种方式。接口做数据分片功能的适配。

Database Mesh 的关注重点在于如何将分布式的数据访问应用与数据库有机串联起来，它更加关注的是交互，是将杂乱无章的应用与数据库之间的交互有效的梳理。同时由于时间位是单调递增的，且各个服务器如果大体做了时间同步，那么生成的主键在分布式环境可以认为是总体有序的，这就保证了对索引字段的插入的高效性。例如 MySQL 的 Innodb 存储引擎的主键。从性能方面来说，由于关系型数据库大多采用B+树类型的索引，在数据量超过阈值的情况下，索引深度的增加也将使得磁盘访问的IO次数增加，进而导致查询性能的下降；

前期业务数据量级不大，流量较低的时候，我们无需分库分表，也不建议分库分表。但是一旦我们要对业务进行分库分表设计时，就一定要考虑到分库分表方案的可持续性。那何为可持续性？其实就是：业务数据量级和业务流量未来进一步升高达到新的量级的时候，我们的分库分表方案可以持续使用。一个通俗的案例，假定当前我们分库分表的方案为10库100表，那么未来某个时间点，若10个库仍然无法应对用户的流量压力，或者10个库的磁盘使用即将达到物理上限时，我们的方案能够进行平滑扩容。

公司最近在搞服务分离，数据切分方面的东西，因为单张包裹表的数据量实在是太大，并且还在以每天60W的量增长。之前了解过数据库的分库分表，读过几篇博文，但就只知道个模糊概念， 而且现在回想起来什么都是模模糊糊的。今天看了一下午的数据库分库分表，看了很多文章，现在做个总结，“摘抄”下来。（但更期待后期的实操） 会从以下几个方面说起：第一部分：实际网站发展过程中面临的问题。第二部分：有哪几种切分方式，垂直和水平的区别和适用面。第三部分：目前市面有的一些开源产品，技术，它们的优缺点是什么。

每次谈到数据库的事务隔离级别,大家一定会看到这张表.其中,可重复读这个隔离级别,有效地防止了脏读和不可重复读,但仍然可能发生幻读,可能发生幻读就表示可重复读这个隔离级别防不住幻读吗?我不管从数据库方面的教科书还是一些网络教程上,经常看到RR级别是可以重复读的,但是无法解决幻读,只有可串行化(Serializable)才能解决幻读,这个说法是否正确呢?在这篇文章中,我将重点围绕MySQL中可重复读（Repeatable read）能防住幻读吗?

隔离级别下，step1 执行时是会隐式的添加 行(X)锁 / gap(X)锁的，从而 step2 会被阻塞，step3 会正常执行，待 T1 提交后，T2 才能继续执行（主键冲突执行失败），对于 T1 来说业务是正确的，成功的阻塞扼杀了扰乱业务的T2，对于T1来说他前期读取的结果是可以支撑其后续业务的。事务默认隔离级别，是事务安全与性能的折中，可能也符合二八定律（20%的事务存在幻读的可能，80%的事务没有幻读的风险），我们在正确认识幻读后，便可以根据场景灵活的防止幻读的发生。

Q：什么是触发器？A：　　触发器是与表有关的数据库对象，在满足定义条件时触发，并执行触发器中定义的语句集合。触发器的特性：　　1、有begin end体，begin end;之间的语句可以写的简单或者复杂　　2、什么条件会触发：I、D、U　　3、什么时候触发：在增删改前或者后　　4、触发频率：针对每一行执行　　5、触发器定义在表上，附着在表上。也就是由事件来触发某个操作，事件包括INSERT语句，UPDATE语句和DELETE语句；可以协助应用在数据库端确保数据的完整

比如在Northwind数据库中有一个查询为SELECT c.CustomerId,CompanyName FROM Customers cWHERE EXISTS(SELECT OrderID FROM Orders o WHERE o.CustomerID=c.CustomerID) 这里面的EXISTS是如何运作呢？子查询返回的是OrderId字段，可是外面的查询要找的是CustomerID和CompanyName字段，这两个字段肯定不在OrderID里面啊，这是如何匹配的呢？E.