Code365

1. B+tree 结构介绍在Mysql中，索引就是帮助搜索数据的一种有序的数据结构，它以某种方式引用（指向）数据。Mysql中的索引是在存储引擎层实现的，因此不同的存储引擎又有着不同的索引结构，主要包含以下几种：简单介绍下经典的B+tree 的结构：可以看出：所有的数据都会出现在叶子节点，叶子节点形成一个单向链表；非叶子节点仅仅索引数据，具体的数据都是在叶子节点存放的；

数据库-- 查看所有的数据库-- 查看某个数据库的定义信息-- 修改字符集改成utf8，注：不是utf-8，是utf8drop database 库名;-- 删除-- 查看正在使用的数据库-- 是一个函数-- 使用db1数据库use db1;表-- 创建表create table 表名(列名 数据类型(长度) 约束,列名 数据类型(长度) 约束,....-- 查看某个数据库中的所有表-- 查看表结构desc 表名;

MySQL高性能优化实战是一个复杂而系统的过程，它涉及到多个方面的优化策略。

MySQL的复制切换是指在主服务器（Master）出现问题或不可用时，通常涉及将一个从服务器升级为新的主服务器，并使其他从服务器指向新的主服务器，自动或手动将从服务器（Slave）切换为新的主服务器，以确保数据的可用性和系统的连续性。请注意，虽然计划内切换是在可控的环境下进行的，但仍然需要谨慎操作，确保数据的完整性和一致性。计划内切换与计划外切换（如故障切换）的主要区别在于，计划内切换是在可控的环境下进行的，目的是为了避免潜在的问题或进行维护操作，而不是由于紧急事件触发的。：在从服务器上，你可以使用。

这一列显示了mysql在索引里使用的字节数，通过这个值可以算出具体使用了索引中的哪些列。在 select 语句之前增加 explain 关键字，MySQL 会在查询上设置一个标记，执行查询时，会返回执行计划的信息，而不是执行这条SQL（如果 from 中包含子查询，仍会执行该子查询，将结果放 入临时表中）NULL：查询的列未被索引覆盖，并且where筛选条件是索引的前导列，意味着用到了索引，但是部分字段未被索引覆盖，必须通过“回表”来实现，不是纯粹地用到了索引，也不是完全没用到索引。

----+------+---------+ | id | name | balance | +----+------+---------+ | 1 | Jay | 100 | +----+------+---------+ 1 row in set (0.00 sec) 复制代码。可以发现，事务B执行插入操作时，阻塞了~因为事务A在执行select ... lock in share mode的时候，不仅在 id = 3,4 这2条记录上加了锁，而且在id > 2 这个范围上也加了间隙锁。

触发预读机制后，MySQL 一下子把很多相邻区里的数据页加载到缓存里去，这些缓存页如果一下子都放在LRU链表的前面，而且他们其实并没什么人会访问的话，就会导致本来就在缓存里的一些频繁被访问的缓存页在LRU链表的尾部。如果使用简单的LRU链表的机制，其实是漏洞百出的，因为很可能预读机制，或者全表扫描的机制，都会一下子把大量未来可能不怎么访问的数据页加载到缓存页里去，然后LRU链表的前面全部是这些未来可能不怎么会被访问的缓存页！如果是热数据区域的前面1/4的缓存页被访问，是不会移动到链表头部去的。

如果索引了多列，要遵守最左前缀法则。指的是查询从索引的最左前列开始并且不跳过索引中的列。b）当覆盖索引指向的字段是varchar(380)及380以上的字段时，覆盖索引会失效！问题：解决like'%字符串%'索引不被使用的方法？a）使用覆盖索引，查询字段必须是建立覆盖索引字段。

在市面上也有很多的开源的词法解析的工具，比如 LEX，Yacc等。查询优化器的目的就是根据解析树生成不同的执行计划（Execution Plan），然后选择一种最优的执行计划，MySQL 里面使用的是基于开销（cost）的优化器，哪种执行计划开销最小，就用哪种。这两种执行方法的逻辑结果是一样的，但是执行的效率会有不同，如果有这么多种执行方式，这些执行方式怎么得到的？查询执行计划展示了接下来执行查询的具体方式，比如多张表关联查询，先查询哪张表，在执行查询的时候有多个索引可以使用，实际上该使用哪些索引。

前言早期从事运单系统的开发和维护工作，从最早的日均百万单，到日均千万单，业务的快速发展再加上外卖业务的特点是，业务量集中在午高峰和晚高峰两个高峰期，所以高峰期并发请求量也是水涨船高，每天都要面对高并发的挑战。拿运单系统来举例，日常午高峰核心查询服务的 QPS 在 20 万以上，Redis 集群的 QPS 更是在百万级，数据库 QPS 也在 10 万级以上，TPS 在 2 万以上。在这么大的流量下，主要的工作也是以围绕如何建设系统的稳定性和提升容量展开，下面主要从基础设施、数据库、架构、应用、规范这几

如果id2只有1和2， 那么31 且 32 所以3输出了，但是 id2包含空值，那么 3也不等于NULL 所以它不会输出。并没有，一位大神曾经说过，如果是确定且有限的集合时，可以使用。如 IN （0，1，2）。是一定会报错: 消息 207，级别 16，状态 1，第 11 行 列名 'id1' 无效。t1表 和 t2表 都是150w条数据，600M的样子，都不算大。IN 和 NOT IN 是比较常用的关键字，为什么要尽量避免呢？然而使用了IN的子查询就是这么敷衍，直接查出 1 2 3。

SDK 支持透出takeSnapshot 、removeSnapshot 方法，业务在项目中自行调用。

通过现场的cloud dba监控也可以发现，innoDB缓存命中率为100%，不存在物理读的情况，也即可以认为数据库的高频数据都已全量存在于内存中了，通过查看数据库容量也可以佐证这个观点，数据+索引大小6G左右，未达到数据库实例配置的8G，所以实际情况是数据都存在于内存中了，并不会有多余的IO操作，CPU的性能全部都消耗在了大量的内存数据扫表(逻辑读)中 - 看现场平均扫描16w行数据；这个结论让我不禁想到了一个类似的场景，在线上vi打开服务器中大文件导致load飙高，应用不可用的问题。

在解决缓存一致性的过程中，有多种途径可以保证缓存的最终一致性，应该根据场景来设计合适的方案，读多写少的场景下，可以选择采用“ Cache-Aside 结合消费数据库日志做补偿”的方案，写多的场景下，可以选择采用“ Write-Through 结合分布式锁”的方案 ，写多的极端场景下，可以选择采用“ Write-Behind ” 的方案。

lag 提供对当前行之前的给定物理偏移的行的访问lead 提供对当前行之后的给定物理偏移量的行的访问通过这两个函数可以在一次查询中取出同一字段的前 n 行的数据 lag 和后 n 行的数据 lead 作为独立的列, 更方便地进行进行数据过滤可用场景在比较同一个相邻的记录集内两条相邻记录计算今日电表消耗(需计算今日电表度数和昨日差值)

本文主要基于团队实际开发经验与积累，并结合了业界对大数据SQL的使用与优化，尝试给出相对系统性的解决方案。背景目前市面上大数据查询分析引擎层出不穷，如Spark，Hive，Presto等，因其友好的SQL语法，被广泛应用于各领域分析，公司内部也有优秀的ODPS SQL供用户使用。笔者所在团队的项目也借用ODPS SQL去检测业务中潜在的安全风险。在给业务方使用与答疑过程中，我们发现大多含有性能瓶颈的SQL，主要集中在数据倾斜与数据膨胀问题中。

但是在字段很多的时候使用，却会大大降低查询效率。因为exists查询的理解就是，先执行主查询，获得数据后，再放到子查询中做条件验证，根据验证结果（true或者false），来决定主查询的数据结果是否得意保留。都满足SQL需求的前提下，推荐优先使用Inner join（内连接），如果要使用left join，左边表数据结果尽量小，如果有条件的尽量放到左边处理。因为SQL优化器是根据表中数据量来进行查询优化的，如果索引列有大量重复数据，Mysql查询优化器推算发现不走索引的成本更低，很可能就放弃索引了。

1 人赞同了该文章。

思路五中，需要将全量数据存在到路由关系表中建立索引，再结合 range 分库分表方案思想，其实有些场景下完全没有必要全部数据建立索引，可以按照号段式建立区间索引，我们可以将分片键的区间对应库的关系通过关系表记录下来，每次查询操作，先去路由表中查询到数据所在的库表索引，然后再到库表中查询详细数据。从上述代码中可以看出，其唯一不同是在计算库索引和表索引时，采用 TableCnt 作为基数（注：扩容操作时，一般采用库个数 2 倍扩容），这样在扩容时，表个数不变，则表索引不会变。从而实现库表数据偏斜率调整。

考虑到所有数据库在设计的过程中都可能遇到这些问题，ANSI就制定了一个SQL标准，其中最著名的就是SQL92标准，其中定义了「不可重复读」和「幻读」（当然也定义了脏读，但鉴于没啥异议，我就没截图），我把其中的重点单词给大家标注了一下，希望大家能彻底搞懂两者的区别。因此SQL标准再次发挥了作用，他们建议数据库厂家按照他们的规范，提供给用户4种隔离级别，让用户根据自己的业务需要权衡利弊，选择合适的隔离级别，以此解决所有的并发读问题（脏读、不可重复读、幻读）或者对某些无关紧要的并发读问题做出妥协。

其实还是一个 b+ 树，每个节点是几个字段值 concat 起来的元组，比如复合索引 (a, b) 的 b+ 树上，对 (a) 列是有序的，对 (a, b)组合列也是有序的，但是对 (b) 列却不一定是有序的，对其叶子节点上带的 pk 列也是无序的。而删除外部表的时候，hive 仅仅删除外部表的元数据，数据是不会删除的，也就是说，外部表的数据其实不是 hive 自己管理的。列表中涉及的业务信息表，用户信息表全部都是大表，列表性能很差，短期内想分表需要改的业务太多，急需提高整体合同列表的性能。

而当线程 B 从数据库读取完数据、更新了缓存后，线程 A 才开始更新数据库，此时，会导致缓存中的数据是旧值，而数据库中的是最新值，产生“数据不一致”。无并发请求下，在更新数据库和删除缓存值的过程中，因为操作被拆分成两步，那么就很有可能存在“步骤 1 成功，步骤 2 失败” 的情况发生（由于单线程中步骤 1 和步骤 2 是串行执行的，不太可能会发生 “步骤 2 成功，步骤 1 失败” 的情况）。先删除缓存值再更新数据库，有可能导致请求因缓存缺失而访问数据库，给数据库带来压力，也就是缓存穿透的问题。

update emp set sal='4000',deptno=2 where ename='zhangsan'delete from emp where ename='zhangsan'grant select,insert on test.* to 'test'@'localhost' identified by '123'show grants for 'test'@'localhost'

MySQL semijoin也被称为半连接，主要是解决外查询一个或多个表的记录在包含一个或多个表的子查询结果中的存在性问题，比如IN/EXIST子查询。如果按照IN/EXIST谓词的原语义去执行，对外查询的每行记录都去计算IN/EXIST谓词的结果，子查询的内容就需要单独执行，在关联子查询的情况下，子查询需要多次重复执行，整体的执行效率很低。实际上，部分存在性问题(SPJ 子查询)类似于外查询的多个表与子查询的多个表(以下简述为外表和内表)的连接(JOIN)问题，能连接上说明存在。

MySQL建表只有10条，大伙可以参考借鉴。1. 表达是否概念的字段，必须使用is_xxx的形式命名；2. 数据类型必须是 unsigned tinyint；3. 1表示是，0表示否；举例：是否删除正确：使用is_deleted，1表示删除，0表示未删除错误：deleted, if_deleted, delete_or_not1. 表名，字段名禁止出现大写；MySQL在Windows下不区分大小写，Linux下虽然区分，但为了避免节外生枝，统一禁止大写。