前言深入理解 index merge 是使用索引进行优化的重要基础之一。理解了 index merge 技术，我们才知道应该如何在表上建立索引。MySQL在分析执行计划时发现走单个索引的过滤效果都不是很好,对多个索引分别进行条件扫描，然后将它们各自的结果进行合并(intersect/union)。我们的 where 中可能有多个条件(或者join)涉及到多个字段，它们之间进行 AND 或者 OR，
主键1、如果我们定义了主键(PRIMARY KEY)，那么InnoDB会选择主键作为聚集索引。如果没有显式定义主键，则InnoDB会选择第一个不包含有NULL值的唯一索引作为主键索引。如果也没有这样的唯一索引，则InnoDB会选择内置6字节长的ROWID作为隐含的聚集索引(ROWID随着行记录的写入而主键递增，这个ROWID不像ORACLE的ROWID那样可引用，是隐含的)。2、数据记录本身被
存，少读多写加队列带事务的不要整体commit，分段commit一、要保证数据库的效率，要做好以下四个方面
行锁MySQL的行锁都是在引擎层实现的，但是 MyISAM 不支持行锁，意味着并发控制只能使用表锁，同一张表任何时刻只能被一个更新在执行，影响到业务并发度。InnoDB 是支持行锁的，这也是 MyISAM 被 InnoDB 替换的重要原因之一。行锁就是针对数据库中表的行记录的锁，这很好理解，比如事务 A 更新了一行，而这时候，事务 B 也要更新一行，则必须等事务 A 的操作完成后才能更新。两阶段锁
什么是长事务运行时间比较长，长时间未提交的事务，也可以称之为大事务。这类事务往往会造成大量的阻塞和锁超时，容易造成主从延迟，要尽量避免使用长事务。下面我将演示下如何开启事务及模拟长事务： #假设我们有一张stu_tb表，结构及数据如下stu_id 唯一索引mysql> select * from stu_tb;+--------------+--------+----------+-----
CPU 利用率过高原因在 MySQL 使用过程中，出现 CPU 利用率过高甚至超过100%时，与数据库存在低效 SQL 或大量行锁冲突有非常大的关系，一般都是由于大量低效的 SQL 导致，出现行锁冲突的概率非常低。风险若 MySQL CPU 的利用率长时间处于100%，会严重影响数据库的整体性能，极端情况下可能会出现实例 HANG 住的情况。 为避免业务因 CPU 资源不足而受影响，建议提前对 C
10379&sub=0B126347AFB347B8ACDD337A5A808D05一. Redis性能如此高的原因纯内存操作,内存的读写速度非常快 单线程,保证了每个操作的原子性,省去了很多上下文切换线程的时间 高效的数据结构,如压缩表，对短数据...
通用规则是：多读少写加缓存，少读多写加队列带事务
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
