1030024444162706_个人页

2024年07月

• 07.05 09:21:51
  发表了文章 2024-07-05 09:21:51

  MySQL数据库碎片化：隐患与解决策略

  UUID作为主键可能导致MySQL存储碎片，影响性能。频繁的DML操作、字段长度变化和非顺序插入（如UUID）都会造成碎片。碎片增加磁盘I/O，降低查询效率，浪费空间，影响备份速度。建议使用自增ID，固定长度字段，并适时运行OPTIMIZE TABLE来减少碎片。
• 07.03 09:14:52
  发表了文章 2024-07-03 09:14:52

  ✅MySQL用了函数到底会不会导致索引失效

  MySQL 8.0 引入了函数索引，打破了传统观念，允许在索引中使用函数，提升查询性能。通过创建基于表达式的索引，如 `CONCAT`、`SUBSTRING_INDEX`、`YEAR`、`MONTH` 等，可以优化涉及这些函数的查询。虽然提高了某些查询速度，但也会增加数据维护成本。应谨慎使用，确保表达式确定且适用于常见查询模式。示例包括基于字符串、日期、数学运算和JSON属性的索引。

  
• 07.01 13:27:32
  发表了文章 2024-07-01 13:27:32

  一篇文章聊透索引失效有哪些情况及如何解决

  MySQL索引失效可能导致慢查询。排查时使用`EXPLAIN`检查执行计划，关注`key`、`type`和`extra`字段。有效索引使用表现为`key`非NULL，`type`为ref、eq_ref、range、const，`extra`含"using index"。失效可能因索引未建、区分度低、表小、函数操作、类型不匹配、OR条件、LIKE通配符开头、隐式类型转换、不等于操作。通过创建合适索引、调整SQL语句和避免函数运算来优化。

2024年06月

• 06.28 12:45:32
  发表了文章 2024-06-28 12:45:32

  「性能指标」CPU飙高排查实战

  在新应用接入高流量业务后，CPU利用率在压力测试中飙升。通过`top`命令发现Java进程占用CPU高。使用Arthas工具定位到JDBC的TCP套接字读取导致阻塞，问题源于频繁的数据库交互。代码优化后，初始化Sequence实例减少数据库交互，CPU使用下降。后续发现预发布环境的日志采集工具开启导致额外CPU消耗，关闭该功能后问题完全解决。排查CPU问题需耐心和系统性分析。

  
• 06.26 09:48:59
  发表了文章 2024-06-26 09:48:59

  聊聊性能指标CPU利用率如何计算的

  **摘要：** CPU 利用率衡量了CPU被程序占用的程度，反映了一段时间内CPU忙碌的程度。在多任务操作系统中，CPU通过时间片分配给各进程实现“并发”。Linux命令如`uptime`、`top`、`w`和`vmstat`可用来监控CPU利用率。`vmstat`中的`%us`、`%sy`、`%id`等指标揭示了不同状态的CPU使用情况。`top`命令则实时显示进程资源占用。CPU利用率过高可能表明系统负载过大或程序问题，需要优化。Java应用中，CPU飙高可能由内存泄漏或死循环引起，需使用jstack等工具排查。
• 06.24 09:22:01
  发表了文章 2024-06-24 09:22:01

  真实线上问题之数据库死锁如何解决？

  数据库死锁发生在并发事务间，彼此等待资源导致僵局。死锁由资源竞争、未释放资源、事务速度差异和大范围操作引起。解决方案包括降低隔离级别、缩短事务时间、固定资源访问顺序和减少操作量。即使操作单条记录也可能死锁，因锁涉及索引。死锁需满足互斥、占有等待、不可抢占和循环等待四个条件。解决可通过资源抢占或避免循环等待。在MySQL中，死锁可能导致TDDL-4614错误，排查通常涉及事务日志分析和顺序调整。
• 06.24 09:20:52
  发表了文章 2024-06-24 09:20:52

  ✅难得真实的生产数据库死锁问题排查过程

  在MySQL 5.7的InnoDB环境中，一个生产问题涉及死锁，发生在更新`fund_transfer_stream`表时。死锁由两个并发事务引起，各自持有不同索引的锁并等待对方释放。事务1持有`idx_seller_transNo`索引锁，等待`PRIMARY`索引锁；事务2相反。问题源于`fund_transfer_order_no`的前20位相同导致的索引冲突，而这是非唯一索引。解决方法包括调整索引前缀长度或确保所有更新通过主键ID进行。死锁排查需查看执行计划和死锁日志，理解MySQL的加锁机制。

  
• 06.19 09:34:30
  发表了文章 2024-06-19 09:34:30

  ✅系统日活递增，如何优化提升大规模数据库

  数据库性能优化涵盖硬件升级（如SSD、内存）、数据库设计简化、SQL查询优化、索引管理、缓存利用（如Redis）、负载均衡（读写分离、集群）、分区分片、备份恢复策略及性能监控。综合调整这些方面可提升系统性能和可用性。[MySQL索引设计][1]和[SQL优化实践][2]是深入学习的好资源。
• 06.17 10:26:54
  发表了文章 2024-06-17 10:26:54

  ✅生产问题之Emoji表情如何操作存储,MySQL是否支持

  MySQL支持存储Emoji表情，需使用UTF8MB4编码。UTF8MB3，MySQL早期的UTF-8实现，不支持部分Unicode字符包括Emoji，已被弃用。推荐使用UTF8MB4，它支持全部Unicode字符。转换时，现有UTF8MB3表需转换为UTF8MB4，列和表都需设置相应字符集。
• 06.15 00:07:07
  发表了文章 2024-06-15 00:07:07

  ✅线上紧急问题之Using filesort 能优化吗，怎么优化？

  当MySQL执行计划显示`Using filesort`，意味着数据需外部排序，通常因`ORDER BY`无法直接利用索引。这可能导致性能下降，尤其处理大量数据时。优化`filesort`可包括：\n1. 设计索引以支持ORDER BY列，尤其是复合索引匹配列顺序。\n2. 调整`sort_buffer_size`以适应排序需求，但要注意内存使用平衡。文章中提到的SQL查询因`GROUP BY`和`ORDER BY`未充分利用索引导致`filesort`，通过创建新索引解决了问题，改进执行计划并消除了`filesort`，从而解决慢查询问题。

  
• 06.12 11:14:52
  发表了文章 2024-06-12 11:14:52

  ✅分析SQL执行计划，我们需要关注哪些重要信息

  SQL执行计划解析：12个关键字段详解，包括id（操作标识）、select_type（操作类型）、table（涉及表）、partitions（分区）、type（索引类型）、possible_keys（可能的索引）、key（使用索引）、key_len（索引长度）、ref（比较对象）、rows（扫描行数）、filtered（过滤比例）和Extra（额外信息）。类型从优至劣：system>const>eq_ref>ref>range>index>ALL。
• 06.11 09:49:09
  发表了文章 2024-06-11 09:49:09

  binlog、redolog和undolog区别？

  MySQL的binlog、redo log和undo log各有特色：binlog用于备份、恢复和复制，记录所有DDL和DML；redo log保障事务持久性，用于崩溃恢复；undo log保证事务原子性和一致性，用于回滚。redo log记录数据修改，undo log记录修改前状态。这三种日志在InnoDB存储引擎中起关键作用，binlog则适用于所有引擎。
• 06.07 14:15:46
  发表了文章 2024-06-07 14:15:46

  MySQL中insertOrUpdate的功能如何实现的

  MySQL中的`INSERT INTO ... ON DUPLICATE KEY UPDATE`语句实现insertOrUpdate功能，当遇到重复键时，会更新已有记录。该操作需要表有主键或唯一索引，且冲突时加临时键锁可能引发死锁。例如，向student表插入数据，如果id已存在则更新name和age。底层实现包括检查唯一索引、处理冲突和执行更新。类似语句有REPLACE INTO和INSERT IGNORE INTO。在主键冲突更新时，自增主键计数器仍会增加，即使未实际插入新记录。
• 06.05 09:45:46
  发表了文章 2024-06-05 09:45:46

  ✅简聊limit 0,100和limit 10000000,100一样吗？

  MySQL的`LIMIT m n`在处理深度分页时性能下降，因为它先读取m+n条数据再抛弃m条。`LIMIT 10000000,100`比`LIMIT 0,100`性能差，因为它涉及大量无用数据读取。优化包括：MySQL可能为少量记录查询使用索引，`ORDER BY`结合`LIMIT`可提前停止排序，`DISTINCT`与`LIMIT`结合时找到唯一行即停止，`LIMIT 0`快速返回空结果集。注意，无索引的`ORDER BY`加`LIMIT`可能导致不确定结果，解决方案是添加确保唯一性的排序字段。
• 06.03 09:10:05
  发表了文章 2024-06-03 09:10:05

  ✅count(1)、count(*) 与 count(列名) 的区别

  COUNT(1)、COUNT(\*)和COUNT(列名)在MySQL中用于统计行数。COUNT(\*)是SQL标准，MySQL对其优化，尤其在无WHERE条件下，MyISAM存储引擎能直接返回总行数。COUNT(1)与COUNT(\*)性能相近，但在某些情况下，MySQL可能对COUNT(\*)有特别优化。COUNT(列名)只计算非NULL值，性能较慢。推荐使用COUNT(\*)，它是标准语法且优化良好。InnoDB处理COUNT(\*)和COUNT(1)无性能差异。COUNT(字段)需检查NULL，性能相对较慢。

  

2024年05月

• 05.31 09:35:56
  发表了文章 2024-05-31 09:35:56

  ✅order by 是怎么实现的？

  MySQL的ORDER BY通过优化器选择索引排序或filesort。索引排序适用于查询条件符合索引最左前缀的情况，而filesort会在内存(sort_buffer)或临时文件中进行。当数据量超过sort_buffer_size，filesort会使用磁盘辅助，速度减慢。全字段排序在sort_buffer中一次性处理所有字段，适合字段少的情况；row_id排序只存储排序字段和主键，减少内存占用，但可能增加回表次数。优化器会权衡速度、内存和回表次数来选择合适的方法。

  
• 05.29 09:05:20
  发表了文章 2024-05-29 09:05:20

  被追着问UUID和自增ID做主键哪个好，为什么？

  讨论了UUID和自增ID作为数据库主键的优缺点。UUID全局唯一，适合分布式系统，但存储空间大，不适合范围查询。自增ID存储空间节省，查询效率高，但分库分表困难，可预测性高。UUID版本包括基于时间戳（V1）、随机数（V4）以及基于名称空间的MD5（V3）和SHA1（V5）散列。

  
• 05.27 09:12:09
  发表了文章 2024-05-27 09:12:09

  ✅什么是最左前缀匹配？为什么要遵守？

  MySQL 的最左前缀匹配原则是指查询时利用索引的最左边列进行匹配。如果创建了组合索引 (col1, col2, col3)，查询条件包括 col1、(col1, col2) 或全列时，MySQL 可以高效利用索引。反之，如果条件仅涉及 col2、col3 或 (col2, col3)，则通常无法利用该索引。虽然查询条件顺序可变，但不涉及最左列时，无法使用索引。MySQL 8.0 引入了索引跳跃扫描，允许在某些情况下不遵循最左前缀匹配，提高查询效率。然而，是否使用取决于优化器的成本估算，并受特定条件限制。设计索引时，仍应优先考虑高区分度的字段。

  
• 05.24 09:22:02
  发表了文章 2024-05-24 09:22:02

  ✅什么是聚簇索引和非聚簇索引、以及回表、索引下推

  数据库中的聚簇索引和非聚簇索引是两种不同的数据组织方式。聚簇索引将数据与索引一起存储，主键决定行的物理顺序，适用于InnoDB。非聚簇索引则索引与数据分开，叶子节点存储主键值和指针。在查询时，非聚簇索引需回表操作找到主键后再查询数据。无主键时，InnoDB会自动生成隐藏主键。覆盖索引和索引下推是优化查询的技术，覆盖索引允许仅通过索引获取数据，减少回表；索引下推可在存储引擎层面部分执行过滤条件，降低回表次数。
• 05.24 09:21:13
  发表了文章 2024-05-24 09:21:13

  ✅MySQL是如何保证唯一性索引的唯一性的？

  MySQL使用B树实现唯一性索引，确保高效检索和插入。事务机制和锁定协议维护InnoDB存储引擎的唯一性。唯一索引可允许NULL值，且InnoDB允许多个NULL。唯一索引查询速度快，能提升数据质量，但插入和更新时需检查唯一性，可能影响性能。
• 05.22 09:03:22
  发表了文章 2024-05-22 09:03:22

  ✅InnoDB为什么使用B+树实现索引？

  InnoDB使用B+树实现索引，因其具备平衡特性、所有数据存储在叶子节点利于范围查询和排序，且非叶子节点仅含索引关键字，能存储更多数据，减少IO操作并优化缓存利用率。B+树与哈希索引的区别在于，后者适用于等值查询但不支持范围查询和排序，且磁盘访问效率较低。相比于红黑树和B树，B+树更适合数据库索引需求。
• 05.20 09:42:44
  发表了文章 2024-05-20 09:42:44

  ✅Innodb加索引，这个时候会锁表吗？

  MySQL 5.6 引入 Online DDL 技术，允许在创建或删除 InnoDB 索引时不阻塞其他会话，减少了锁定和性能影响。不同 DDL 操作支持不同方式，如 COPY、INSTANT 和 INPLACE，具体见官方文档。虽然 Online DDL 可减少阻塞，但可能在索引构建期间仍有锁定，建议在非高峰时段执行并做好测试和规划。MySQL 5.6 之前的 DDL 操作会导致表锁定，而 Online DDL 旨在减少这种阻塞，但并非所有 DDL 语句都适用。了解各种算法如 COPY、INPLACE 和 INSTANT，以及它们的工作原理，有助于优化 DDL 操作。
• 05.17 09:29:29
  发表了文章 2024-05-17 09:29:29

  ✅乐观锁与悲观锁如何实现

  在MySQL中，悲观锁通过`SELECT ... FOR UPDATE`在InnoDB引擎实现，需关闭自动提交，确保数据修改时的独占性，防止并发修改。乐观锁则利用CAS机制，通过版本号避免冲突，更新时检查数据是否已变更。悲观锁适合写操作频繁且并发高的场景，乐观锁适合读多写少，效率较高但可能导致更新失败。选择哪种锁取决于业务需求和并发情况。
• 05.15 09:09:14
  发表了文章 2024-05-15 09:09:14

  ✅什么是排他锁、共享锁、意向锁

  共享锁（读锁）允许并发读取数据，阻止修改；排他锁（写锁）则允许读取和修改，排斥其他锁。在MySQL中，`SELECT ... LOCK IN SHARE MODE;`添加共享锁，`SELECT ... FOR UPDATE;`添加排他锁。意向锁用于多粒度锁定，解决行锁与表锁的并发问题，分为意向共享锁（读）和意向排他锁（写），在事务请求行锁或表锁时自动获取，释放于事务结束。
• 05.13 09:41:39
  发表了文章 2024-05-13 09:41:39

  MySQL的行级锁锁的到底是什么？

  本文简述了InnoDB的行级锁机制，包括记录锁、间隙锁和Next-Key锁。记录锁锁定索引记录，防止其他事务对相同值的行进行操作；间隙锁锁定索引记录间的间隙，防止插入。Next-Key锁是两者的结合，锁定记录及其前后间隙。在可重复读(RR)隔离级别下，加锁策略涉及Next-Key锁，但会因查询条件退化为行锁或间隙锁。MySQL的加锁机制遵循两个原则和两个优化，例如唯一索引等值查询时退化为行锁。RR级别虽能防止幻读，但也可能降低并发并引发死锁，因此有些场景下会选择读已提交(RC)级别。

  
• 05.11 09:14:12
  发表了文章 2024-05-11 09:14:12

  介绍下InnoDB的锁机制？

  InnoDB存储引擎的锁分为共享锁（S锁，读锁）和排他锁（X锁，写锁）。共享锁允许多个事务并发读取数据，不允许修改；排他锁允许读取和修改数据，阻止其他事务加锁。SELECT ... LOCK IN SHARE MODE和SELECT ... FOR UPDATE分别用于获取共享锁和排他锁。此外，还有意向锁（IX，IS）用于协调行级锁和表级锁的并发问题，意向锁在事务请求锁时自动获取。记录锁锁定索引记录，插入记录锁用于插入操作前的间隙锁定，而AUTO-INC锁确保自增列的有序性。
• 05.02 18:26:32
  发表了文章 2024-05-02 18:26:32

  ✅浅聊MVCC？

  MVCC（多版本并发控制）是数据库的一种并发控制方法，通过快照读和当前读实现优雅的并发操作。快照读读取快照数据，而当前读获取最新数据，涉及加锁。Undo Log存储记录的旧版本，用于回滚事务和MVCC的快照读。行记录包含隐式字段如db_trx_id和db_roll_ptr，用于追踪记录版本。Read View解决数据可见性问题，根据事务ID判断记录是否对当前事务可见。MVCC结合Read View和Undo Log确保在可重复读隔离级别下避免不可重复读问题。

  
• 04.28 09:28:51
  发表了文章 2024-04-28 09:28:51

  Innodb的RR到底有没有解决幻读？

  InnoDB的Repeatable Read隔离级别结合间隙锁和MVCC能缓解大部分幻读问题，但不完全解决。彻底解决幻读需使用Serializable隔离级别。MVCC通过快照读避免事务内多次查询的幻读，而间隙锁在当前读时锁定间隙，防止新插入记录。然而，当事务中既有快照读又有当前读时，仍可能出现幻读。解决幻读的最佳选择是使用Serializable隔离级别，但可能增加死锁风险。

  
• 04.25 09:38:16
  发表了文章 2024-04-25 09:38:16

  ✅为什么MySQL默认使用RR隔离级别？

  Oracle默认隔离级别为RC，MySQL选择RR。Oracle的Read Committed最适合默认，因为它不锁定读取的数据，利于并发。而MySQL的RR级别防止了某些并发问题，特别是考虑到其历史上的statement格式binlog，该格式在READ COMMITTED下可能导致主从数据不一致。MySQL的RR通过行级锁定保证数据一致性，适合有主从复制的环境。

  
• 03.25 09:58:05
  发表了文章 2024-03-25 09:58:05

  对线面试官 - 如何理解MySQL的索引覆盖和索引下推

  索引下推是MySQL 5.6引入的优化，允许部分WHERE条件在索引中处理，减少回表次数。例如，对于索引(zipcode, lastname, firstname)，查询`WHERE zipcode='95054' AND lastname LIKE '%etrunia%'`时，索引下推先过滤zipcode，然后在索引中应用lastname条件，降低回表需求。索引下推可在EXPLAIN的`Using index condition`中看到。

  
• 03.21 15:57:02
  发表了文章 2024-03-21 15:57:02

  ✅到底有没有必要分库分表，如何考量的

  是否需要分库分表取决于数据量、负载、增长速度、查询需求、扩展性、容错性和维护成本。当单表数据量接近2000万时，由于B+树结构，查询效率可能下降。B+树的高度和数据页限制了单表容量，通常保持在3-4层，以保证查询性能。以3层B+树、16KB数据页和1KB/行数据为例，可存约2000万条数据。权衡业务需求和技术因素，适时决定是否分表。
• 03.18 15:51:28
  发表了文章 2024-03-18 15:51:28

  真正线上索引失效的问题是如何排查的

  MySQL索引失效是一种常见问题，在处理慢查询时经常需要考虑索引失效的可能性。 针对索引失效的排查，关键步骤包括确定需要分析的SQL语句，并通过`EXPLAIN`查看其执行计划。主要关注`type`、`key`和`extra`这几个字段。

  
• 03.15 10:49:26
  发表了文章 2024-03-15 10:49:26

  MySQL的JOIN到底是怎么玩的

  在MySQL中，查询操作通常会涉及到联结不同表格，而JOIN命令则在这一过程中扮演了关键角色。在JOIN操作中，我们通常会使用三种不同的方式，分别是内连接、左连接以及右连接。
• 03.14 11:15:48
  发表了文章 2024-03-14 11:15:48

  日活3kw下，如何应对实际业务场景中SQL过慢的优化挑战？

  在面试中，SQL调优是一个常见的问题，通过这个问题可以考察应聘者对于提升SQL性能的理解和掌握程度。通常来说，SQL调优需要按照以下步骤展开。

2022年10月

• 10.24 18:03:23
  发表了文章 2022-10-24 18:03:23

  JVM-Java虚拟机内存模型

  Java内存模型在1.8之前和1.8之后略有不同，也就是运行时数据区域，请看如下图：

  
• 10.24 18:02:06
  发表了文章 2022-10-24 18:02:06

  自定义注解判断参数为空

  使用Spring的 @Valid和@Validated不好嘛，干嘛要自己造轮子呢.......

  

2022年07月

• 07.30 20:45:57
  发表了文章 2022-07-30 20:45:57

  走进 Redis，让你重新认识 redis。绝不是表面

  说到Redis我们不禁的会联想到：缓存。提到缓存我们要聊的就有很多了。