xpzhang123的专栏

在 MySQL 中，只有一种 Join 算法，就是大名鼎鼎的 Nested Loop Join，他没有其他很多数据库所提供的 Hash Join，也没有 Sort Merge Join。顾名思义，Nested Loop Join 实际上就是通过驱动表的结果集作为循环基础数据，然后一条一条的通过该结果集中的数据作为过滤条件到下一个表中查询数据，然后合并结果。如果还有第三个参与 Join，则再通过前两

具体如下：1、创建一个临时表，临时表有一个字段 a，并且在这个字段 a 上创建一个唯一索引;2、遍历表 t，依次取数据插入临时表中 2.1 如果发现唯一键冲突，就跳过 2.2 否则插入成功；3、遍历完成后，将临时表作为结果集返回给客户端。...

之前连着写了几篇关于 MySQL 中常用操作的一些基本实现原理，如，MySQL ORDER BY，MySQL Join，这次再写一篇 MySQL 中 GROUP BY 的基本实现原理。由于 GROUP BY 实际上也同样会进行排序操作，而且与 ORDER BY 相比，GROUP BY 主要只是多了排序之后的分组操作。当然，如果在分组的时候还使用了其他的一些聚合函数，那么还需要一些聚合函

大家都知道索引对于数据访问的性能有非常关键的作用，都知道索引可以提高数据访问效率。为什么索引能提高数据访问性能？他会不会有“副作用”？是不是索引创建越多，性能就越好？到底该如何设计索引，才能最大限度的发挥其效能？这篇文章主要是带着上面这几个问题来做一个简要的分析，同时排除了业务场景所带来的特殊性，请不要纠结业务场景的影响。索引为什么能提高数据访问性能？很多人只知道索

作者：Sky.Jian | 可以任意转载, 但转载时务必以超链接形式标明文章原始出处 和 作者信息 及 版权声明 链接：http://isky000.com/database/index_scan_or_full_table_scan |  del.icio.us | Twitter it | Hosted On DreamHost 可以通过我的折扣码 iMySQLer 获得优惠折

对于任何一个数据库管理系统来说，内存的分配使用绝对可以算的上是其核心之一了，所以很多希望更为深入了解某数据库管理系统的人，都会希望一窥究竟，我也不例外。从内存的使用方式MySQL 数据库的内存使用主要分为以下两类线程独享内存全局共享内存今天这篇文章暂时先分析 MySQL 中主要的 “线程独享内存” 的。在 MySQL 中，线程独享内存主要用于各客户端连接线程

总的来说，在 MySQL 中的ORDER BY有两种排序实现方式，一种是利用有序索引获取有序数据，另一种则是通过相应的排序算法，将取得的数据在内存中进行排序。下面将通过实例分析两种排序实现方式及实现图解：假设有 Table A 和 B 两个表结构分别如下：sky@localhost : example 01:48:21> show create table A\G

DISTINCT 实际上和 GROUP BY 操作的实现非常相似，只不过是在 GROUP BY 之后的每组中只取出一条记录而已。所以，DISTINCT 的实现和 GROUP BY 的实现也基本差不多，没有太大的区别。同样可以通过松散索引扫描或者是紧凑索引扫描来实现，当然，在无法仅仅使用索引即能完成 DISTINCT 的时候，MySQL 只能通过临时表来完成。但是，和 GROUP BY 有一点差别的

很多人都将 数据库设计范式 作为数据库表结构设计“圣经”，认为只要按照这个范式需求设计，就能让设计出来的表结构足够优化，既能保证性能优异同时还能满足扩展性要求。殊不知，在N年前被奉为“圣经”的数据库设计3范式早就已经不完全适用了。这里我整理了一些比较常见的数据库表结构设计方面的优化技巧，希望对大家有用。由于MySQL数据库是基于行（Row）存储的数据库，而数据库操作 IO 的时候是以 pa

MySQL 的存储引擎可能是所有关系型数据库产品中最具有特色的了，不仅可以同时使用多种存储引擎，而且每种存储引擎和MySQL之间使用插件方式这种非常松的耦合关系。由于各存储引擎功能特性差异较大，这篇文章主要是介绍如何来选择合适的存储引擎来应对不同的业务场景。MyISAM特性不支持事务：MyISAM存储引擎不支持事务，所以对事务有要求的业务场景不能使用表级锁定：其

在平时被问及最多的问题就是关于 MySQL 数据库性能优化方面的问题，所以最近打算写一个MySQL数据库性能优化方面的系列文章，希望对初中级 MySQL DBA 以及其他对 MySQL 性能优化感兴趣的朋友们有所帮助。这是 MySQL数据库性能优化专题 系列的第一篇文章：MySQL 数据库性能优化之缓存参数优化数据库属于 IO 密集型的应用程序，其主要职责就是数据的管理及存储工

全局共享内则主要是 MySQL Instance（mysqld进程）以及底层存储引擎用来暂存各种全局运算及可共享的暂存信息，如存储查询缓存的 Query Cache，缓存连接线程的 Thread Cache，缓存表文件句柄信息的 Table Cache，缓存二进制日志的 BinLog Buffer， 缓存 MyISAM 存储引擎索引键的 Key Buffer以及存储 InnoDB 数据和索引的 I

作者：Sky.Jian | 可以任意转载, 但转载时务必以超链接形式标明文章原始出处 和 作者信息 及 版权声明 链接：http://isky000.com/database/mysql-performance-tuning-sql |  del.icio.us | Twitter it | Hosted On DreamHost 可以通过我的折扣码 iMySQLer 获得优惠折扣

在过往与很多人的交流过程中发现，在谈到基于硬件来进行数据库性能瓶颈分析的时候，常被大家误解为简单的使用更为强劲的主机或者存储来替换现有的设备。个人觉得这其中可能存在一个非常大的误区。我们在谈论基于硬件进行优化的时候，不能仅仅将数据库使用的硬件划分为主机和存储两部分，而是需要进一步对硬件进行更细的分解，至少也应该分解到如下范畴：主机CPU：仅仅只能决定运算速度，及时是运算

DISTINCT 实际上和 GROUP BY 操作的实现非常相似，只不过是在 GROUP BY 之后的每组中只取出一条记录而已。所以，DISTINCT 的实现和 GROUP BY 的实现也基本差不多，没有太大的区别。同样可以通过松散索引扫描或者是紧凑索引扫描来实现，当然，在无法仅仅使用索引即能完成 DISTINCT 的时候，MySQL 只能通过临时表来完成。但是，和 GROUP BY 有一点差别的

问题描述：Mysql主键自增，加入当前主键是20，删掉该记录之后，在插入一条，主键是20还是21？不同的引擎对于自增值得保存策略不同。1、MySAM 引擎的自增主键保存在数据文件中2、InnoDB 引擎的自增值，其实就是保存在了内存里，并且到了Mysql8.0版本后，才有了“自增持久化”的能力，也就是说“如果发生重启，MySQL自增主键可以恢复为Mysql重启前的值”，具体情况如下...