旷野历程

在 MySQL中，悲观锁是需要依靠数据库提供的锁机制实现的，在 InnoDB 引擎中，使用悲观锁，就需要先关闭 MySQL 数据库的自动提交属性，然后通过 select ... for update 来进行加锁。乐观锁最大的好处就是通过 CAS 的方式做并发校验，这个过程不需要提前加锁，只需要在更新的那一刻加一个短暂的锁而已，而悲观锁的话，需要你先 select ...... for update，锁的时长要长得多。MySQL 中的乐观锁在对数据库进行处理的时候，乐观锁并不会使用数据库提供的锁机制。

乐观锁是相对悲观锁而言的，乐观锁只有在数据进行提交更新的时候，才会对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。如果使用了悲观锁，通常需要在查询时显式地使用 for update 子句，这会将选定的行进行加锁，防止其他事务对其进行修改，直到当前事务结束。乐观并发控制相信事务之间的数据竞争的概率是比较小的，因此尽可能直接做下去，直到提交的时候才去锁定，所以不会产生任何锁和死锁。相对于悲观锁，在对数据库进行处理的时候，乐观锁并不会使用数据库提供的锁机制。

分析MySQL中的数据占用磁盘的大小

2）假设当前 select 的 trx_id 为 102，read-view 中未提交的事务为 [101]，则需要通过 DB_ROLL_PTR 获取上一版本的 trx_id 100，注意 trx_id 为 101 的事务是改变了另一张表的数据，所以 undo 日志里版本链指向的上一条数据 trx_id 为 100，还是会返回 zhangsan。每次 select 数据时生成 read view 列表，再配合 undo 日志中的版本链，让不同的事务读-写，写-读操作可以并发执行，进而实现 MVCC。

这个问题，其实跟慢 SQl 排查解决有点像。

如何定位慢 SQL 呢？可以通过 slow log 来查看慢SQL，默认的情况下，MySQL 数据库是不开启慢查询日志（slow query log）。所以我们需要手动把它打开。可以通过慢查询日志，定位那些执行效率较低的 SQL 语句，重点关注分析。

RU，读未提交解决了脏写问题，但可能出现脏读；RC，读已提交解决了脏读问题，但可能出现不可重复读；RR，可重复读解决了不可重复读的问题，但可能出现幻读；Serializable，串行化解决了幻读的问题，但性能很低。MySQL 是怎么实现事务隔离性的呢？答案是加锁。事务级别越高，解决的并发事务问题越多，同时也意味着加的锁就越多。RU-读未提交 < RC-读已提交 < RR-可重复读 < Serializable-串行化。

MySQL 的执行流程也确实是一个复杂的过程，它涉及多个组件的协同工作，故而在面试或者工作的过程中很容易陷入迷惑和误区。

information_schema.PROCESSLIST 是 MySQL 中的一个系统表，用于提供有关当前执行的 MySQL 进程的信息，包括连接的相关信息、正在执行的查询、连接状态等。在 MySQL 中，要查看指定数据库连接的服务地址，可以查询 information_schema.PROCESSLIST 表来获取有关当前 MySQL 进程的信息，包括连接的服务地址。注意：information_schema.PROCESSLIST 表提供的信息是瞬时的，可能会随时间而变化。

加密方式使用 AES 加密，再转成 Base64。

在数据库中，主键是用于唯一标识数据库表中的每一行数据。主键能够确保数据的唯一性，并在表中建立索引，以提高查询效率。数值型主键和字符型主键各有其适用的场景，需要根据具体需求来选择合适的主键类型。存储空间：数值型型主键相对较小，节省存储空间；而字符型主键根据具体长度而定，可能占据更多的存储空间。查询效率：数值型主键在索引和排序操作上更高效；而字符型主键在特定场景下可能效率更高，如需要根据字符串进行模糊搜索或排序。可读性：字符型主键更直观易懂，方便开发人员和用户理解；

1、先把数据查询出来，根据需要再判断是改为0，或改1。4、使用 CASE 函数。2、使用 ABS 函数。3、使用 IF 函数。

例如，CHAR非常适合存储密码的MD5值，因为这是一个定长的值。对于经常变更的数据，CHAR也比VARCHAR更好，因为定长的CHAR类型不容易产生碎片。例如用CHAR( 1)来存储只有Y和N的值，如果采用单字节字符集只需要一个字节，但是VARCHAR(1)却需要两个字节，因为还有一个记录长度的额外字节。事实证明有很大的优势。更长的列会消耗更多的内存，因为MySQL通常会分配固定大小的内存块来保存内部值。另外，使用VARCHAR(5)和VARCHAR(200)存储'hello'在磁盘空间上开销是一样的。

在需要去除重复值而不需要聚合的情况下，可以使用 DISTINCT 来代替简单的 GROUP BY，以避免不必要的聚合操作，从而提高性能。因为它仅仅关注去除重复值，而不需要对数据进行聚合操作。在需要分组和聚合数据的情况下，GROUP BY 是更合适的选择。最终的选择应该根据你的具体业务需求和性能测试结果来决定，而且性能上的差异还取决于查询的复杂性、表的大小、索引的使用等因素。

选择 合适的字段属性：类型、⻓长度、是否允许NULL等；尽量量把字段设为not null。 要尽量量避免全表扫描，⾸首先应考虑在 where 及 order by 涉及的列列上建⽴立索引。 应尽量量避免在 where ⼦子句句中对字段进⾏行行 null 值判断、使⽤用!= 或 <> 操作符，否则将导致引擎放弃使⽤用索引⽽而进⾏行行全表扫描 应尽量量避免在 where ⼦子句句中使⽤用 or 来连接条件，如果一个字段有索引，一个字段没有索引，将导致引擎放弃使⽤用索引⽽而进⾏行行全表扫描 i

通过查询备份表把符合条件的数据更新到主表中。

【代码】MySQL字段脱敏。

需要注意的是这里的 id 字段被定义为 PRIMARY KEY，即唯一键，所以在插入时会检查唯一键冲突。如果您的表没有唯一键或没有设置合适的唯一约束，"INSERT INTO ... ON DUPLICATE KEY UPDATE" 将不会生效。想要插入一行数据，如果该数据的 id 已经存在于表中，则更新字段；如果 id 在表中不存在，则插入一行新数据。该语法在插入新行时检查是否存在唯一键冲突，如果冲突，则执行更新操作；如果没有冲突，则执行插入操作。

如果您需要执行递归查询，建议您使用 MySQL 版本 8.0 或更高版本，并使用 CONNECT BY 和 START WITH 语法。请注意，MySQL 8.0 版本中，CONNECT BY 语法要求启用递归公用表表达式（Recursive Common Table Expression，RCTE）。在 MySQL 数据库中，WITH RECURSIVE 是递归查询的一种语法。相反，MySQL 提供了另一种递归查询的方法，即使用 CONNECT BY 和 START WITH 语法。

"CREATE TABLE IF NOT EXISTS" 是用于创建表的语法，如果表已经存在，则不会再次创建，而是直接忽略创建操作。如果 "orders_2022" 表不存在的情况下才会执行创建操作，并且其结构与 "orders" 表相同。"CREATE TABLE IF NOT EXISTS" 该语句在使用时，确保数据库用户具有足够的权限来执行表的创建操作。

忽略所有的列而直接统计所有的行数，在统计结果时不会忽略为 NULL 的值。

按照 create_at 排序可能在内存中完成，也可能需要使用外部排序，取决于排序所需的内存和参数 sort_buffer_size。sort_buffer_size 是 mysql 为排序开辟的内存。如果排序数据量小于 sort_buffer_size，排序会在内存中完成。如果数据量过大，内存放不下，则会利用磁盘临时文件排序。

这种写法有些时候比较难以理解，如果关联多张表，就很难看出哪个条件是关联，哪个条件是过滤。

LIMIT 子句可以被用于强制 SELECT 语句返回指定的记录数，LIMIT 接收一个或两个数字参数，参数必须是一个整数常量，如果给定两个参数，第一个参数指定第一个返回记录行的偏移量，第二个参数指定返回记录行的最大数举个简单的例子，分析下 SQL 查询过程MySQL 耗费了 大量随机 I/O 在回表查询聚簇索引的数据上，而这 1000000 次随机 I/O 查询数据不会出现在结果集中。如果系统并发量高一点，且每次查询扫描超过 1000000 行，想想性能会怎么样。

MySQL 存储 IP 地址

执行流程

SQL的编写需要注意的问题

主备延迟的来源

数据库设计和表创建时就要考虑性能

MySQL查询一周前/三个月前/一年前，及昨天、今天、明天、前一个小时和后一个小时的时间

MySQL大表优化方案

SQL查询索引失效之谜

MySQL如何在海量数据的情况下添加新字段

MySQL存储过程创建表

MySQL记录binlog三种模式

MySQL中存放手机号应选择什么数据类型

MySQL中常用数据类型分析

实现MySQL主从同步

MySQL自增主键和手动生成主键区别

MySQL主键类型使用int、bigint、varchar区别