- 博客(537)
- 收藏
- 关注
RSS订阅原创 Apache ShardingSphere 读写分离功能的限制与注意事项
ShardingSphere读写分离功能的主要限制包括：1)主从数据同步延迟导致读写不一致，必须通过事务内读主库或Hint机制处理；2)跨主从库关联查询存在限制，建议避免或强制走主库；3)要求主从库Schema严格一致；4)不支持单库内部读写分离；5)与分布式事务结合使用时存在额外复杂性。开发者需重点关注主从延迟问题，合理设计业务逻辑，并做好监控。这些限制需要在系统设计和开发过程中主动规避和处理。
2025-07-08 00:22:50
88
原创 Apache ShardingSphere 的读写分离功能核心概念详解
Apache ShardingSphere的读写分离功能通过主库(唯一写入点)和从库(多个读取点)提升数据库性能。核心机制包括：逻辑数据源透明路由SQL请求；负载均衡策略分配读请求；主从延迟问题解决方案(事务内强制主库读、Hint管理器)。使用时需注意主库写入与从库读取的数据一致性，合理选择负载均衡策略。该功能对应用透明，显著降低代码复杂度，同时提供灵活的读写控制能力。建议结合实践配置和测试深入理解其工作机制。
2025-07-08 00:21:48
85
原创 Apache ShardingSphere 的读写分离功能
Apache ShardingSphere的读写分离功能通过将写操作路由至主库、读操作分散到从库，有效提升系统读性能与整体吞吐量。该功能包含主库、从库和逻辑数据源三个核心组件，支持轮询、随机等多种负载均衡策略。实现原理包括SQL解析路由、执行与结果归并，其中事务内读操作默认路由至主库以保证一致性，还提供Hint机制强制主库查询。优势在于提升读性能、增强可用性并保持对应用透明，但需注意主从延迟、事务一致性等关键问题。配置支持Java代码、YAML和Spring Boot等方式，建议结合实践场景深入理解延迟影响
2025-07-08 00:20:02
344
原创 ShardingSphere 事务模块的附录内容
ShardingSphere事务模块附录提供关键补充信息，主要包括： XA事务恢复命令 - 详细说明MySQL、PostgreSQL等数据库查询和处理悬挂事务的SQL命令，强调操作风险及日志存储重要性。 Seata AT集成配置 - 给出完整配置示例，重点包括事务组映射、TC集群地址、必须关闭的数据源代理等关键参数。 BASE模式实现 - 提供事务日志表DDL范例和事件监听器接口实现示例，展示如何将事务日志发布到消息队列。 附录内容聚焦实际应用中的关键操作和配置细节，为事务管理提供实用参考。
2025-07-08 00:19:44
220
原创 ShardingSphere 事务功能的限制
ShardingSphere事务功能存在多方面限制，主要包括：1）通用限制如不支持跨数据库类型事务、存储过程事务和Savepoint；2）XA事务受限于底层Narayana/Atomikos实现的资源管理问题；3）Seata AT模式的全局锁竞争、读未提交隔离级别和UNDO LOG依赖风险；4）BASE模式的最终一致性和补偿逻辑实现复杂度。这些限制源于分布式事务的固有复杂性、数据库差异及架构设计，需根据业务场景权衡选择合适方案，并针对性地设计容错机制和监控体系。
2025-07-08 00:17:42
446
原创 ShardingSphere 事务管理的核心概念
本文解析了ShardingSphere事务管理的核心概念体系，包括本地事务、全局事务、分支事务三大基础单元，以及事务管理器、资源管理器两大核心组件。重点阐明了事务上下文和挂起事务的运行机制，揭示了分布式事务在逻辑层与物理层的协同原理。通过剖析各组件职责与交互关系，展现了ShardingSphere如何通过分层架构实现ACID特性，为分布式场景提供标准化事务管理能力。该理论框架是理解ShardingSphere实现XA、Seata等事务模式的基础。
2025-07-08 00:17:19
575
原创 ShardingSphere 的事务管理
ShardingSphere 提供多事务类型支持，核心包括：1) Seata AT柔性事务（低侵入最终一致，需部署Seata TC）；2) 本地事务表（利用数据库本地事务记录日志，异步实现最终一致）；3) XA事务（标准两阶段提交，强一致但性能较差）。选择需权衡一致性、性能与复杂度：Seata AT适合多数场景，XA适用于强一致需求，本地事务表适合无中间件环境。
2025-07-08 00:16:57
518
原创 ShardingSphere 分片附录详解
ShardingSphere 分片核心功能指南 本指南系统化总结了ShardingSphere分片功能的核心内容，包含以下要点： 分片算法表达式语法：详细说明了行表达式语法、时间函数扩展和复合表达式用法，提供Groovy语法示例。 分片配置项全集：列出分片规则配置结构，包括分库/表策略、算法参数表和分布式序列配置，附带YAML示例和参数说明表。 Hint强制路由：介绍SQL Hint语法和Java API两种实现方式，展示如何指定分片值。 弹性伸缩操作：提供DistSQL扩容语法和迁移状态监控命令，包含数据
2025-07-08 00:15:39
514
原创 ShardingSphere 分片限制深度解析与解决方案
ShardingSphere 分片限制与解决方案摘要 ShardingSphere作为分布式数据库中间件存在SQL兼容性、事务性、分片策略和性能等方面的限制。SQL支持方面，DDL语句需包含分片键，DML操作如跨分片更新和多表关联受限，查询语句需注意分片键与聚合操作的内存消耗。事务层面，本地事务完全支持，而分布式事务需根据业务选择XA、Seata等方案。分片策略要求分片键不可变，分片算法选择需考虑扩容和查询需求。性能优化需控制分片数量，避免大数据量归并，合理配置连接池。解决方案包括：SQL改写、分布式事务框
2025-07-08 00:15:10
460
原创 Apache ShardingSphere 内置的分片算法( 自动分片算法、标准分片算法、复合分片算法和 Hint 分片算法)
Apache ShardingSphere 的分片算法可分为四大类型： 自动分片算法：主键自动路由，无需指定分片键，适合主键驱动的业务场景，配置简单但灵活性较低。 标准分片算法：单分片键精确/范围路由，推荐使用 INLINE 或 INTERVAL 算法，适用于大多数分片需求。 复合分片算法：支持多分片键组合路由，需自定义实现，灵活性高但开发复杂。 Hint 分片算法：强制编程指定路由，适用于特殊操作或无分片键查询，侵入性强。 选型建议：优先标准分片，时间驱动用自动分片，复杂场景用复合分片，Hint 作为最后
2025-07-08 00:14:41
330
原创 ShardingSphere-JDBC 分片策略 详解
ShardingSphere-JDBC的分片策略由分片键和分片算法组成，用于决定数据如何路由到不同库表。分片键是数据分片的关键字段（如user_id、order_id等），应选择分布均匀且高频查询的字段。分片算法分为三类：标准分片算法（处理精确查询）、范围分片算法（处理BETWEEN等范围查询）和复合分片算法（处理多分片键场景）。配置上分为数据库分片策略（路由到不同库）和表分片策略（路由到同库不同表），均遵循"分片策略=分片键+分片算法"的公式。此外，绑定表（相同分片规则的表）和广播表（
2025-07-08 00:13:39
533
原创 ShardingSphere 分片核心概念
ShardingSphere分片机制解析 ShardingSphere通过逻辑表与真实表的映射关系实现分布式数据库透明化访问，其核心分片概念包括： 逻辑表作为应用层抽象 真实表对应物理存储 数据节点定义最小存储单元 分片键决定数据路由 分片算法实现精确/范围路由计算 分片策略配置多维分片规则 高级特性包含绑定表避免JOIN笛卡尔积、广播表同步基础数据，以及弹性分片扩容机制。生产实践中需遵循分片键离散性、稳定性等设计原则，合理选择分片算法类型，并按照扩容公式规划分片数量。系统提供SQL解析路由和诊断工具保障分
2025-07-08 00:10:05
779
原创 ShardingSphere 分片核心特性
ShardingSphere分片核心特性解析 摘要：ShardingSphere作为分布式数据库中间件，其分片功能通过智能路由和计算下推实现海量数据管理。核心分片体系包含逻辑表、真实表、数据节点等概念，支持多维分片策略（垂直/水平分片）和多种分片算法（精确/范围/复合分片）。高级特性包括绑定表避免笛卡尔积、广播表同步维度数据、冷热数据分离和动态扩容能力。生产实践中需注意分片键设计原则（高基数性、业务相关、写均匀）和容量规划公式。系统提供SQL兼容性矩阵和故障诊断工具（路由追踪、元数据查询、性能监控），建议单
2025-07-08 00:09:14
462
原创 ShardingSphere-Proxy 快速入门
ShardingSphere-Proxy 是一个透明的数据库网关，提供与原生数据库兼容的协议，支持多语言应用接入。部署流程包括：1）环境准备（Java 8+、MySQL/PostgreSQL）；2）配置全局规则和数据分片策略；3）启动服务并连接。通过 YAML 文件定义分库分表规则，支持动态配置更新和分布式主键生成。生产建议采用高可用部署模式，集成配置中心，并监控性能指标。常见问题包括连接失败、路由异常等，可通过日志分析和配置检查解决。Proxy 适用于生产环境，与 JDBC 驱动搭配使用，支持零停机迁移和
2025-07-08 00:08:19
520
原创 ShardingSphere-JDBC 快速入门
摘要： ShardingSphere-JDBC作为轻量级Java驱动，通过YAML配置快速实现分库分表。核心步骤包括： 引入依赖（ShardingSphere-JDBC+HikariCP）； 配置数据源及分片规则（分库策略、分表策略、雪花ID生成）； 代码集成，通过标准JDBC操作逻辑表，SQL自动路由至物理节点； 支持调试日志、事务管理及SpringBoot集成。 适用于需高性能分片的Java应用，无需代理层，配置简洁高效。注意分片键限制与连接池优化。
2025-07-08 00:07:55
186
原创 联合索引 && 覆盖索引 && 最左前缀原则 && 索引下推 && 回表
数据库索引核心概念解析：1）联合索引在多个列上建立B+树结构，按列顺序存储键值；2）覆盖索引可直接提供查询数据，避免回表操作；3）最左前缀原则要求查询必须从索引左侧列开始使用；4）索引下推在存储引擎层提前过滤数据，减少回表次数；5）回表是通过二级索引查找主键后访问聚簇索引的过程。这些技术相互关联（联合索引是基础，覆盖索引和索引下推可减少回表），合理设计索引（高频列靠左、包含查询字段）能显著提升查询性能。
2025-07-07 00:24:57
177
原创 ShardingSphere-JDBC 详解
Apache ShardingSphere-JDBC 是轻量级 Java 框架，提供分库分表、读写分离、数据加密等分布式数据库增强功能。核心能力包括：灵活的分片算法（支持标准、范围及复合分片）、读写分离负载均衡、多种分布式事务方案（XA/SeAT/Saga）、透明化数据加密和影子库压测支持。其工作流程涵盖SQL解析、路由优化、改写执行和结果归并。作为嵌入式JDBC扩展，它具有无中心化、低侵入等优势，适用于大数据量、高并发及快速增长的Java应用场景。相比ShardingSphere-Proxy，JDBC方案
2025-07-07 00:24:26
574
原创 mysql 主从复制原理、实现方式 以及 主从同步延迟的处理方式
MySQL主从复制是一种异步的数据同步机制，通过主库（Master）将数据变更记录到二进制日志（binlog），从库（Slave）通过三个核心线程（Binlog Dump、I/O、SQL）实现数据同步。复制方式分为基于二进制日志位置和基于GTID两种，后者能自动跟踪事务位置。主从复制模式包括异步复制（默认）、半同步复制和组复制（MGR），各有优缺点。主从延迟问题可通过并行复制、分库分表等方式优化。监控命令SHOW SLAVE STATUS可查看复制状态，常见故障可通过调整配置或跳过事务处理。
2025-07-07 00:23:03
731
原创 MySQL数据库读写分离 以及 实现方式
MySQL读写分离是提升数据库性能和可用性的关键架构，通过将写操作（INSERT/UPDATE/DELETE）路由到主库，读操作（SELECT）分发到从库来实现负载均衡。核心实现方式包括：应用层代码实现（简单但侵入性强）、数据库中间件代理（推荐使用ProxySQL等专业工具）、驱动层实现（如ShardingSphere-JDBC）以及基于DNS的方案（逐渐被淘汰）。关键挑战在于主从延迟和事务处理，可通过强制读主库、GTID等待或半同步复制解决。方案选型需根据项目规模决定，中小项目适合应用层实现，大型系统推荐
2025-07-07 00:22:25
501
原创 MySQL事务的四大特性 以及 ACID 实现机制
MySQL事务的四大特性（ACID）是数据库可靠性的核心保障。原子性（Atomicity）通过Undo Log实现全成功或全失败；一致性（Consistency）由业务规则和数据库约束共同维护；隔离性（Isolation）通过MVCC和锁机制控制并发访问；持久性（Durability）依赖Redo Log确保数据永久保存。MySQL默认采用REPEATABLE READ隔离级别平衡性能与一致性，通过间隙锁避免幻读。实践建议包括合理配置日志参数、避免长事务等，最终目标是通过ACID机制实现数据一致性。
2025-07-07 00:21:53
727
原创 MySQL 中的锁分类
MySQL锁机制是保障数据一致性和并发控制的核心，主要包括全局锁、表级锁和行级锁。全局锁用于全库备份但会阻塞所有写操作；表级锁含表锁、元数据锁和意向锁，其中长事务可能阻塞DDL操作；行级锁由InnoDB实现，含记录锁、间隙锁、临键锁等，需注意索引失效会退化为表锁。锁按兼容性分为共享锁和排他锁，死锁检测可通过等待图实现。最佳实践包括优先使用行锁、避免长事务、监控锁等待及谨慎执行DDL。间隙锁仅在REPEATABLE READ级别有效，无索引更新会导致全表锁。
2025-07-07 00:21:22
571
原创 聚簇索引（Clustered Index）vs 非聚簇索引（Non-clustered Index）
摘要：聚簇索引与非聚簇索引的核心区别在于叶子节点存储内容。聚簇索引存储实际数据行，数据物理顺序与索引一致，每表仅限一个，适合主键和范围查询但插入较慢；非聚簇索引存储数据指针，不影响物理顺序，每表可建多个，查询可能需回表但插入更快。聚簇索引更新代价高，非聚簇索引更灵活。设计时应将主键设为聚簇索引，为常用查询列建非聚簇索引，考虑覆盖索引避免回表。不同数据库引擎实现有差异，理解两者区别对优化性能至关重要。（150字）
2025-07-07 00:20:53
606
原创 B+ 树 VS B 树
B+树和B树是两种重要的多路平衡搜索树，主要用于数据库和文件系统索引。B+树仅叶子节点存储数据，非叶节点为纯索引，叶子节点通过双向链表连接，这使得它比B树具有更低的树高、更高的空间利用率和更高效的范围查询能力。B+树的这些特性使其在数据库索引中占据主导地位，尤其适合磁盘I/O密集型操作和大规模数据扫描。而B树由于数据分散存储，在内存数据库或特定写密集型场景中可能略有优势。实际测试显示，B+树在范围查询和全表扫描上的性能远超B树，成为现代数据库系统的首选索引结构。
2025-07-07 00:19:31
420
原创 mysql 创建索引 注意事项
在MySQL中，合理创建索引是优化查询性能的关键，但需注意以下几点：1.明确目标查询，只为高频关键查询创建；2.遵循最左前缀原则设计组合索引；3.优先使用覆盖索引避免回表；4.控制索引数量避免冗余；5.选择区分度高的列。创建时需注意前缀索引优化、排序分组匹配、NULL值处理等问题，避免函数导致索引失效。生产环境应采用Online DDL、避开高峰期操作。后期要定期监控使用情况、更新统计信息并处理碎片化。最佳实践是保持"少而精"原则，基于实际负载决策，平衡读写性能。
2025-07-07 00:17:57
637
原创 MySQL 索引失效的 10 大原因及深度解析
MySQL索引失效是数据库性能优化的关键问题。本文总结了10大常见原因：违反最左前缀原则、对索引列进行计算/函数操作、使用OR连接非索引列、模糊查询以%开头、优化器成本估算放弃索引、负向查询、JOIN字段类型不匹配、索引合并效率低、数据分布不均以及索引物理损坏。每种情况都给出具体示例和解决方案，如重写查询条件、调整索引顺序、强制使用索引提示等。最后强调通过EXPLAIN分析执行计划来诊断问题，重点关注type、key等字段。掌握这些优化技巧可有效提升查询性能。
2025-07-07 00:17:41
837
原创 MySQL 索引的分类
MySQL索引分类与选型指南 MySQL索引主要分为三类：按数据结构划分（B+Tree、Hash、全文、空间索引）、按物理存储划分（聚簇索引与非聚簇索引）、按逻辑功能划分（普通、唯一、主键、前缀、组合索引等）。其中B+Tree索引是最常用类型，支持范围查询和排序；Hash索引仅适合等值查询；聚簇索引决定数据物理存储顺序。组合索引需遵循最左前缀原则。 【选型建议】 优先使用B+Tree索引 精确匹配且数据量小时可选Hash索引 文本搜索用全文索引 空间数据用R-Tree索引 多列查询使用组合索引并注意最左前缀
2025-07-07 00:17:22
408
原创 MySQL EXPLAIN 详解
MySQL 的 EXPLAIN 是分析 SQL 性能的核心工具，通过解读执行计划优化查询效率。关键字段包括： type（访问类型）：从最优的 system 到最差的 ALL，至少应达到 range 级别 key（实际使用索引）：优先选择覆盖索引 rows（预估扫描行数）：数值越小性能越好 Extra（额外信息）：重点关注 Using index（覆盖索引）、Using temporary（临时表）等提示 核心优化点： 通过索引优化避免 ALL 全表扫描 利用覆盖索引减少回表操作 注意 Using files
2025-07-07 00:17:03
440
原创 MySQL EXPLAIN ANALYZE ( MySQL 8.0+ 新工具 )
MySQL 8.0.18引入的EXPLAIN ANALYZE工具将执行计划与实际性能数据结合，提供更精准的查询分析。它会实际执行查询并收集详细指标（耗时、处理行数、循环次数等），以树形结构展示执行计划与真实度量。关键优势在于能对比优化器预估与实际结果，精确定位性能瓶颈如行数估算偏差、无效索引使用和高耗时操作。语法为EXPLAIN ANALYZE <查询>，输出包含各节点的预估成本与实际执行数据（单次/总耗时、处理行数、循环次数）。典型应用场景包括分析连接顺序、索引效率及排序操作等，但需注意它会真
2025-07-07 00:16:45
515
原创 MySQL 的 PROFILE (MySQL 5.7 及之前版本 可用) 详解
MySQL 的 PROFILE 工具是分析SQL查询性能的关键功能，它能详细展示查询各阶段的资源消耗（时间、CPU、IO等），帮助定位性能瓶颈。通过SET profiling=1启用后，执行SHOW PROFILES查看查询列表，再用SHOW PROFILE CPU FOR QUERY [ID]分析具体查询。重点关注耗时高的阶段如Sending data、Sorting result等。注意该功能在MySQL 5.6.7+被弃用，推荐使用Performance Schema或MySQL 8.0+的EXPLA
2025-07-07 00:16:20
524
原创 MySQL 慢 SQL详解
MySQL慢SQL分析与优化指南 慢SQL是数据库性能瓶颈的主要原因，常见问题包括索引失效（未建索引、函数操作）、SQL写法不当（SELECT *、复杂JOIN）、数据量过大及锁竞争等。定位慢SQL可使用慢查询日志、EXPLAIN分析执行计划、Performance Schema监控和SHOW PROCESSLIST实时查看。 优化手段包括： 索引优化：避免函数操作，遵循最左前缀原则 SQL重写：子查询转JOIN，优化深分页查询 架构优化：分库分表、读写分离 高级技巧：利用索引覆盖和索引下推减少回表 建议建
2025-07-07 00:16:03
867
原创 MySQL 的两阶段提交（Two-Phase Commit, 2PC）
阶段主要操作目的关键日志控制参数PrepareRedo Log 写盘 +fsync+ 标记 PREPARE确保事务修改的物理页变更持久化，为提交或回滚做准备Redo LogBinlog 写盘 +fsync(根据设置)确保事务的逻辑操作记录持久化，用于复制和恢复BinlogCommitRedo Log 标记 COMMIT (通常异步刷盘)在引擎层正式提交事务，释放资源，数据可见Redo Log (状态更新)只要 Binlog 成功写入并刷盘，该事务在引擎层一定可以成功提交。
2025-07-06 15:06:09
565
原创 MySQL binlog 和 redo log 区别
MySQL 的 Binlog 和 Redo Log 是两种核心但不同的日志机制。Binlog 是 MySQL Server 层的逻辑日志，用于主从复制和数据恢复，记录 SQL 语句或行变更；Redo Log 是 InnoDB 引擎层的物理日志，用于崩溃恢复，记录数据页修改。Binlog 在事务提交后写入，可长期保留；Redo Log 在事务进行中持续写入，循环覆盖。两者通过两阶段提交机制协作保障数据一致性。理解它们的差异对掌握 MySQL 数据持久化、复制和恢复机制至关重要。
2025-07-06 15:03:16
481
原创 InnoDB 和 MyISAM 区别
MySQL的InnoDB和MyISAM是两种主要存储引擎，存在显著差异。InnoDB支持事务、行级锁、外键约束和崩溃恢复，采用MVCC机制提高并发性，默认使用聚集索引存储数据。MyISAM则不支持事务和外键，采用表级锁，数据与索引分离存储，COUNT(*)查询更快但崩溃恢复能力弱。自MySQL 5.5起，InnoDB成为默认引擎，适用于大多数需要事务和高并发的场景；MyISAM仅适用于特定场景，如读多写少、不需要事务的表。
2025-07-06 14:57:27
544
原创 MySQL 的日志文件 详解
MySQL日志文件详解 MySQL日志文件是其数据一致性和可靠性的核心保障，主要分为事务日志和二进制日志两大类。事务日志包括重做日志(Redo Log)和回滚日志(Undo Log)，分别用于确保事务持久性和支持事务回滚/MVCC。二进制日志(Binlog)则用于主从复制和时间点恢复。不同日志在写入机制、内容格式和配置优化上各有特点，共同构建了MySQL的高性能、高可靠特性。合理配置日志参数(如innodb_flush_log_at_trx_commit、sync_binlog等)对系统性能和数据安全至关重
2025-07-06 14:53:23
706
原创 MySQL 的 `bin` 目录详解
MySQL 的 bin 目录包含数据库核心管理工具，主要分为六类：1) 核心服务器程序（如 mysqld 主进程、mysqld_safe 安全启动器）；2) 客户端工具（mysql 命令行客户端、mysqladmin 管理工具）；3) 备份恢复工具（mysqldump 逻辑备份、mysqlbinlog 日志处理）；4) 维护诊断工具（mysqlcheck 表检查、mysql_upgrade 版本升级）；5) 安装初始化工具（mysqld --initialize 数据目录初始化）；6) 辅助工具（mysql
2025-07-06 14:53:01
740
原创 MySQL 的基础架构
MySQL 采用分层模块化架构，主要分为三层：连接层负责身份验证和线程管理；服务层处理 SQL 解析、优化和执行，包含日志系统；存储引擎层（如 InnoDB、MyISAM）负责数据存储，InnoDB 提供事务支持、缓冲池和日志机制（redo/undo log）。系统数据库存储元数据和性能信息，整体设计兼顾高效查询与数据安全。
2025-07-06 14:52:41
828
原创 InnoDB 的 Buffer Pool 详解
摘要：InnoDB的Buffer Pool是MySQL的核心内存组件，作为磁盘和内存之间的高速缓存层，主要作用是缓存数据页和索引页，减少磁盘I/O，提升数据库读写性能。其内部通过Free List、LRU List和Flush List等机制管理内存页，采用改进的LRU算法进行页面淘汰。关键特性包括预读机制、脏页刷新策略、多实例化设计等。Buffer Pool大小设置对性能至关重要，建议设为物理内存的50%-75%。MySQL 5.6+支持Buffer Pool预热功能，可通过SHOW ENGINE INN
2025-07-06 14:52:01
671
原创 MySQL 的 常用命令
MySQL常用命令分类总结：涵盖数据库操作（创建/删除/选择数据库）、表管理（创建/修改/删除表）、数据CRUD（增删改查）、索引管理、用户权限控制、事务处理、备份恢复及系统信息查询等核心功能。精选实用示例包括：创建带自增主键的用户表、条件查询订单、批量插入产品数据、事务控制及mysqldump备份等。特别标注高危操作警示（如DROP DATABASE），建议配合备份使用。该清单整合了MySQL日常管理90%的场景需求，命令均以英文分号结尾，SQL关键字推荐大写提升可读性。
2025-07-06 14:19:42
196
原创 MySQL 查询语句的执行顺序
MySQL查询语句的执行顺序与书写顺序完全不同，主要分为9个逻辑阶段：1.FROM/JOIN确定数据源；2.ON应用连接条件；3.WHERE行级过滤；4.GROUP BY分组聚合；5.HAVING组级过滤；6.SELECT选择列；7.DISTINCT去重；8.ORDER BY排序；9.LIMIT分页。关键区别在于WHERE在GROUP BY前执行，而HAVING在后，且SELECT阶段才能使用列别名。优化建议包括：尽早用WHERE过滤、避免SELECT*、谨慎使用排序和大分页。掌握执行顺序是SQL性能优化的
2025-07-06 13:57:19
842
原创 mysql -- count(1)、count(*) 与 count(列名) 的区别
MySQL 中 COUNT(1)、COUNT(*) 和 COUNT(列名) 的主要区别在于统计方式和性能优化： 统计目标：COUNT(*) 和 COUNT(1) 统计所有行（含 NULL），COUNT(列名) 只统计非 NULL 值 性能优化：InnoDB 引擎中 COUNT(*) 会优先使用最小二级索引，比 COUNT(主键) 更快；MyISAM 直接读取元数据 使用建议：统计总行数用 COUNT(*)；统计非 NULL 列用 COUNT(列名)；避免使用 COUNT(主键) 执行计划：COUNT(*)
2025-07-06 13:45:09
574
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人