回答：MySQL InnoDB 引擎底层数据结构是 B+ 树，所谓的索引其实就是一棵 B+ 树，一个表有多少个索引就会有多少颗 B+ 树，MySQL 中的数据都是按顺序保存在 B+ 树叶子节点上的。
聊一个实际问题：淘宝的数据库，主键是如何设计的？ 某些错的离谱的答案还在网上年复一年的流传着，甚至还成为了所谓的MySQL军规。其中，一个最明显 的错误就是关于MySQL的主键设计。
该文章专注于面试，面试只要回答关键点即可，不需要对框架有非常深入的回答，如果你想应付面试，是足够了，抓住关键点
某些错的离谱的答案还在网上年复一年的流传着，甚至还成为了所谓的MySQL军规。其中，一个最明显的错误就是关于MySQL的主键设计。
开头还是介绍一下群，如果感兴趣polardb ,mongodb ,mysql ,postgresql ,redis 等有问题，有需求都可以加群群内有各大数据库行业大咖，CTO，可以解决你的问题。加群请联系 liuaustin3 ，在新加的朋友会分到2群。
如果你的业务设计依赖于自增主键的连续性，这个设计假设自增主键是连续的。但实际上，这样的假设是错的，因为自增主键不能保证连续递增。
本篇讲解 Mysql 的「主键」问题，从「为什么」的角度来了解 Mysql 主键相关的知识，并拓展到主键的生成方案问题。再也不怕被问到 Mysql 时只知道 CRUD 了。
PS：MySQL索引底层数据结构详细分析过程参考这篇深入分析MySQL索引底层原理
在 第4篇 文章中，我们提到过自增主键，由于自增主键可以让主键索引尽量地保持递增顺序插入，避免了页分裂，因此索引更紧凑。
我没想到她会来这一出，我从我爸碗里夹回我的鸡腿，对女儿说道：不是，你这样问问你爷爷
构建分布式系统时，如何对数据进行唯一标识也是一个至关重要的设计。不仅要符合B-tree数据结构以维持查询性能，还要考虑唯一标识的连续性会不会影响系统安全性。在分库分表的情况下，还要避免唯一标识重复且高效等等需要考虑的点。为此，市场就出现了很多分布式ID生成方案。本文将详细介绍九种主流的分布式ID生成策略供大家参考使用。
自增主键没有持久化是个比较早的bug，这点从其在官方bug网站的id号也可看出（https://bugs.MySQL.com/bug.php?id=199）。由Peter Zaitsev（现Perco
分布式系统中，全局唯一 ID 的生成是一个老生常谈但是非常重要的话题。随着技术的不断成熟，大家的分布式全局唯一 ID 设计与生成方案趋向于趋势递增的 ID，这篇文章将结合我们系统中的 ID 针对实际业务场景以及性能存储和可读性的考量以及优缺点取舍，进行深入分析。本文并不是为了分析出最好的 ID 生成器，而是分析设计 ID 生成器的时候需要考虑哪些，如何设计出最适合自己业务的 ID 生成器。
AUTO_INCREMENT=2，表示下一次插入数据时，若需要自动生成自增值，会生成id=2。
我们在设计表结构的时候，经常会对某一列设置自增长的值，它的作用是可以帮助我们自动递增某一列的值，自增长的属性经常被设置在主键列上，原因是主键必须具有唯一性，而自动增长可以避免重复，二者结合恰到好处。除此之外，自增长的属性还可以避免在数据插入的时候，出现大量的数据页分裂操作，关于这一点，后面说到索引的时候，会着重介绍，现在我们只需要知道，主键一般设置成自增长的即可。
最近在极客时间上学习丁奇大佬的《MySQL 45讲》，这里结合自己的理解分享出来，喜欢的同学可以购买原版课程进行学习，里面的内容很丰富。
需要按照自增ID字段进行增量查询，有些表的自增ID是主键，而有些表的自增只是普通索引，有些采用MyISAM，有些采用InnoDB。
学习MySQL的知识，学习好索引是非常重要的，索引分类、索引如何正确添加、索引失效的场景、底层数据结构等问题是面试中必问的，就这些内容我们一起学习巩固下。
关于发号器的使用，其实有一个大背景，那就是关于主键的一些设计问题，在MySQL中如果一张表没有主键，实际的数据处理就有点麻烦了。
可以看到表定义中出现了AUTO_INCREMENT=2，表示下一次插入数据时如果需要自动生成自增值，那么id便是2。
自增主键：特指在自增列上定义的主键。 自增主键的优点是让主键索引保持递增顺序的插入，避免页分裂，索引更加紧凑。
依托于互联网的发达，我们可以随时随地利用一些等车或坐地铁的碎片时间学习以及了解资讯。同时发达的互联网也方便人们能够快速分享自己的知识，与相同爱好和需求的朋友们一起共同讨论。
这篇文章主要讲述了在单机数据库环境下如何进行优化，包括表结构优化、字符集选择、字段设计、索引创建等方面，同时指出了一些注意事项。
然后插入数据，最后看到，表会自动生成一个AUTO_INCREMENT的值，ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT CHARSET=latin1 ,表示下一次插入数据时，如果需要自动生成自增值，会生成 id=11。
最近有客户反馈，说线上服务在一小段时间内出现偶发的请求失败情况，需要我们排查并给出具体问题。对于这样的问题，我们一般都会猜疑是不是网络抖动，但是需要有理有据的解释清楚问题，还是要基于日志事实求事去分析。在日志中我发现的报错是这个样子的：
第二范式：在第一范式的基础上，非主键列完全依赖于主键，而不能是依赖于主键的一部分。
长期以来，在 MySQL 的开发规范里一般都会这么写：禁止大事务！话题转到 TiDB ，依然应该是：禁止大事务！
表中t1~t5的(ID,grade)值分别为(1,70)、(2,80)、(3,90)、(4,100)和(5,110)， 此时两棵索引树的示例示意图如下。
之前的文章把 InnoDB 中的所有的锁都介绍了一下，包括意向锁、记录锁...自增锁巴拉巴拉的。但是后面我自己回过头去看的时候发现，对自增锁的介绍居然才短短的一段。
☆ 点击▲关注 腾讯云数据库 ☆ ---- 2019年9月，腾讯云数据库正式按地域发布TXSQL 5.7-201908版本，该版本主要实现写性能提升，新增功能特性和内核参数，为MySQL提供更稳定、高效的性能和服务能力。其中，新增特性包括DROP大表操作异步化、GTID复制功能扩展、隐藏主键功能、非 Super 权限用户 Kill 链接的功能等。另外，在最新的TXSQL内核版本中，可以通过内核参数来指定事务调度算法。下面将为大家详细解读。 TXSQL的演进之路 相信大家对腾讯云数据库Tence
MySQL 作为使用范围最广的开源关系型数据库，是每个后端开发人员都绕不开的一道坎。我在上一篇文章中也写了关于 MySQL 中的 MVCC 的细节及各个隔离级别如何使用 MVCC，有兴趣的可以查看。
大型网站为了解决大量的高并发访问问题，除了在网站实现分布式负载均衡，远远不够。到了数据业务层、数据访问层，如果还是传统的数据结构，或者只是单单靠一台服务器支持，如此多的数据库连接操作，服务器性能再好数据库必然会崩溃。数据丢失的话，后果更是不堪设想。这时候，我们会考虑如何减少数据库的连接，一方面采用优秀的代码框架，进行代码的优化，采用优秀的数据缓存技术如：memcached等。如果资金充足的话，必然会想到假设服务器集群，来分担主数据库的压力。或者在硬件设备上，投入大量资金，购买高性能的服务器。出名的有f5，硬件负载，软件负载等。 Ok切入今天的主题，利用MySQL主从配置，实现读写分离，减轻数据库压力。这种方式，在如今很多网站里都有使用，也不是什么新鲜事情，今天总结一下，方便大家学习参考一下。 读写分离： 1.多个服务器肯定比一个服务器好。 2.在数据库写入的时候，会加入大量的锁(排它锁,共享锁等等)，从而影响性能。 3.数据更安全,多数据库存在备份数据。 搭建环境： 1.搭设一台Master服务器（win7系统64bit,Ip：10.10.2.33） 2.一台台Slave服务器（winXp系统32bit,ip:10.10.2.157） 原理：主服务器（Master）负责网站写操作，从服务器负责查询操作。主从服务器利用MySQL的二进制日志文件，实现数据同步。二进制日志由主服务器产生，从服务器响应获取同步数据库。
在实际业务场景中，经常会有这样的需求：插入一条记录，如果数据表中已经存在该条记录则更新它的部分字段，比如更新update_time或者在某些列上执行累加操作等。参考博客1中介绍了三种在MySQL中避免重复插入记录的方法，本文将在简单介绍这三种用法的基础上，深入分析这其各自存在的问题，最后给出在实际生产环境中对该业务场景的最佳实践。
在MySQL数据库中，主键自增是一种常见的技术，用于自动为表中的主键字段生成唯一的递增值。本文将深入讨论MySQL主键自增的原理、用途、使用方法，以及在实践中的注意事项和最佳实践。
今天是《MySQL核心知识》专栏的第4章，今天跟大家一起聊聊MySQL的简单语法。好了，开始今天的正题。
锁是计算机协调多个进程或纯线程并发访问某一资源的机制。在数据库中，除传统的计算资源（CPU、RAM、I/O）的争用以外，数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所在有数据库必须解决的一个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来说，锁对数据库而言显得尤其重要，也更加复杂。
索引的出现是为了提高查询效率，但是实现索引的方式却有很多种，所以这里也就引入了索引模型的概念。可以用于提高读写效率的数据结构很多，这里我先给你介绍三种常见、也比较简单的数据结构，它们分别是哈希表、有序数组和搜索树。
以Col1为主键，则上图是一个MyISAM表的主索引（Primary key）示意
小A正在balabala写代码呢，DBA小B突然发来了一条消息，“快看看你的用户特定信息表T，里面的主键，也就是自增id，都到16亿了，这才多久，在这样下去过不了多久主键就要超出范围了，插入就会失败，balabala......”
最近在项目中用了UUID的方式生成主键，一开始只是想把这种UUID的方式生成主键记录下来，在查阅资料的过程中，又有了一些新的认识和思考。
一、MySQL的数据类型 数据类型是定义列中可以存储什么类型的数据以及该数据实际怎样存储的基本规则 数据类型限制存储在数据列列中的数据。例如，数值数据类型列只能接受数值类型的的数据 在设计表时，应该特别重视所用的数据类型。使用错误的数据类型可能会严重地影响应用程序的功能和性能。 更改包含数据的列不是一件小事（而且这样做可能会导致数据丢失）。 数据类型：整型、浮点型、字符串、日期等 ------------------------------------ 1、字符串数据类型 最常用的数据类型是串数据类型。它们
MySQL在创建表时，如果你没有显示的创建主键，那么innodb会自动帮你创建一个不可见的、长度是6字节的row_id，所有未定义主键的表共享该row_id，每次插入一条数据row_id加1。
（下面这张图为计算机组成原理内容，每查询一次索引节点，都会进行一次磁盘IO读取，即要寻道和旋转）
(2).非聚簇索引 联合索引 前缀索引 普通索引 唯一索引 全文索引
其实上面这些问题，我最早想法是，每个问题都可以啰嗦出一篇文章。后来由于良心发现，烟哥就决定用一篇文章将这些问题都讲明白。 当然，我给的回答可能并非标准答案，毕竟是自己的一些工作总结。各位读者有更好的回答，也欢迎交流！
1. 锁类型 锁是数据库区别与文件系统的一个关键特性，锁机制用于管理对共享资源的并发访问。 InnoDB使用的锁类型，分别有： 共享锁（S）和排他锁（X） 意向锁（IS和IX） 自增长锁（AUTO-INC Locks） 1.1. 共享锁和排他锁 InnoDB实现了两种标准的行级锁：共享锁（S）和排他锁（X） 共享锁：允许持有该锁的事务读取行记录。如果事务 T1 拥有记录 r 的 S 锁，事务 T2 对记录 r 加锁请求：若想要加 S 锁，能马上获得；若想要获得 X 锁，则请求会阻塞。 排他锁：允许持有该锁
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
