研发在早期的设计中,由于设计方面的问题,导致在设计表结构的时候,有个表有非空唯一索引而没有主键 在InnoDB存储引擎中,如果没有主键的情况下,有非空唯一索引的话,非空唯一索引即为主键. 那么这就会有个问题存在 应用在更新表的时候,用了 update aaaa ) ) 用了ID作为条件,修改,高事务并发下,可能会同时发生这种事务,由于id并没有任何索引,故此,表会被全锁,也就是全表.那么如何避免这个问题.我们线上的数据 暂时还不是很大,故此 drop index idx_aaa_unique o
某系统反馈慢SQL影响生产,查看SLOW LOG发现下面慢SQL: SELECT COUNT(DISTINCT m.batch_no) FROM ob_relation r INNER JOIN ob_batch_d d ON r.sub_order_no = d.outbound_no INNER JOIN ob_batch_m m ON d.batch_no = m.batch_no WHERE r.production_mode =1 AND r.yn=0 AND r.outbound_n
一.背景 随着公司业务的发展,商品库存从商品中心独立出来成为一个独立的系统,承接主站商品库存校验.订单库存扣减.售后库存释放等业务.在上线之前我们对于核心接口进行了压测,压测过程中出现了 MySQL 5.6.35 死锁现象,通过日志发现引发死锁的只是一条简单的sql,死锁是怎么产生的?发扬技术人员刨根问底的优良传统,对于这次死锁原因进行了细致的排查和总结.本文既是此次过程的一个记录. 在深入探究问题之前,我们先了解一下 MySQL 的加锁机制. 二.MySQL 加锁机制 首先要明确的一点是 My
Mysql 系列文章主页 =============== Tips:在阅读本文前,最好先阅读 这篇(Mysql锁机制--行锁)文章~ 在上篇文章中,我们看到InnoDB默认的行锁可以使得操作不同行时不会产生相互影响.不会阻塞,从而很好的解决了多事务和并发的问题.但是,那得基于一个前提,即 Where 条件中使用上了索引:反之,如果没有使用上索引,则是全表扫描.全部阻塞.本文就以实际例子来演示这种情景. 1 准备数据 1.1 建表 DROP TABLE IF EXISTS employee; CR
检查集群的健康情况 GET /_cat/health?v green:每个索引的primary shard和replica shard都是active状态的yellow:每个索引的primary shard都是active状态的,但是部分replica shard不是active状态,处于不可用的状态red:不是所有索引的primary shard都是active状态的,部分索引有数据丢失了 快速查看集群中有哪些索引 GET /_cat/indices?v 创建索引 PUT /test_inde