dweizhao的专栏

场景一：多线程并行插入，插入失败则更新导致的死锁(不易排查, 事务隔离级别RR和RC都会出现)场景描述有一个每日交易任务，当交易额度满足一定数量时，就可以增加一次任务完成记录(user_no和trade_date组成唯一索引)；实现流程如下:1.当有交易来的时候，先查询当天该用户是否已经发生过交易了；模拟sql: select xx1,xx2 from trade where user_no = vv3 and trade_date = vv42.如果当前交易不存在则进行插入或更新(主要

前两节对分库分表和遇到一些问题进行解释和总结，本节对分库分表的数据存储和划分原则进行一个讲解数据存储分别是：独立存储+缓存：适用于数据量少，基本不变的数据；读写分离 ： 适用于数据量适中，增长平缓，读多写少的数据水平切分： 适用于数据量大，增长快速，读写频繁的数据划分原则能不分就不分，当单表记录达到一定数量级（>1000万）之后才考虑进行水平切分处理；分片字段取决于最频繁的查询SQL，选择合适的切分规则，避免跨库聚合，跨库事务；分片数量尽量少，分片尽量均匀分布在多个 DataH

单一DB如图所示，这是单一DB的应用架构，db中主要包括三种业务类型的表，分表是用户、订单、商品。而对应业务操作基本都是在一个应用中完成的，这种架构适合项目周期短、业务简单 用户相对不多需求，因为用户量少压力就不是特别大，基本一个DB完全可以支撑而随着公司的业务规模逐渐扩大，带来的效果就是用户量和业务的复杂度日益增加， 这时这种架构就会出现一系列问题，比如响应过慢，有时候甚至会出现超时。而通过

上一节介绍了分库分表的的产生背景，以及遇到的一些问题，本节对上节遇到问题进行一个总结并给出一些解决方案。问题列表引入分布式事务的问题跨节点join的问题跨节点排序分页的问题高并发下原子性的问题以上是对分库分表遇到一些问题进行了汇总，下面对这些问题以及对应的解决方案一一讲解。引入分布式事务的问题同一应用系统-引入分布式事务的问题如图所示，这是一个注册操作步骤，注册服务由两个原子服务组成，分别为：登录标识原子服务认证信息原子服务。其中登录标识对应的登录标识表对应分片键为登录标识，因

MySql的索引统计分析在捣鬼，他预估的索引唯一值Cardinality，还是按原数据进行预估为70W，这次插入了850W，当执行查询的时候，发现重复数据占比70/920=1/13,查询优化器发现重复率太高，放弃走索引，所以导致了全表扫描。

第一种：root@ubuntu:/usr/local/mysql# mysql -hlocalhost -uroot -proot;mysql>use mysql;mysql> insert into user (host,user,password) values('%','test',password('test'));//固定IP则替换%mysql> FLUSH

预估数据表中索引中唯一值数据。此值与实际数据条数越接近，走索引的几率就越高。如果需要更新此值则需要执行ANALYZE TABLE 或适用于MyISAM引擎的myisamchk -a。Cardinality统计更新发生在两个操作中：insert、update。根据前面介绍Cardinality统计不是每次都进行的，因此InnoDB引擎对于 更新Cardinality的策略为： 表中的1/16数据已发生变化start_modified_counter>2 000 000 000