sql

精选推荐

最新动态

mysql并发事务中如何避免长事务_mysql性能风险说明

2026年2月24日

长事务本身不直接消耗 CPU，但会持续持有锁、阻止 MVCC 清理、拖慢 purge 线程，最终让整个实例响应变慢甚至卡死。最典型的信号是 SHOW ENGINE INNODB STATUS 中看到大量 TRX_WAITING 或 purge lag 持续上涨。

SQL Liquibase 的 precondition failed 的变更回滚处理模板

2026年2月24日

不是数据库挂了，也不是 Liquibase 坏了，而是你在 changeSet 里写的 preConditions 没通过校验——比如表不存在、列类型不匹配、SQL 查询返回非空结果等。Liquibase 在执行前卡在这一步，直接中断，后续变更不会跑，也不会自动回滚已执行的上一个 changeSet。

mysql数据库中的命令历史记录与权限审计

2026年2月24日

MySQL 客户端（mysql 命令行工具）默认会把执行过的 SQL 写入用户家目录下的 ~/.mysql_history 文件，但这个行为受多个条件限制：
• 只有在未设置环境变量 MYSQL_HISTFILE 为 /dev/null 或空字符串时才生效
• 若用户以 mysql -e "SELECT 1" 方式执行命令，语句不会写入历史文件
• ~/.mysql_history 是纯文本、无时间戳、无用户标识、无连接上下文，无法区分是哪个账号、连的哪台实例、何时执行的
• 文件权限若配置不当（如被其他用户可读），反而构成安全风险

mysql表锁与行锁各有什么优缺点_mysql性能对比分析

2026年2月24日

表锁直接锁整张表，MySQL不用查索引、不定位行，所以加锁快、开销小。MyISAM默认就用它，不会死锁——因为锁的只有“表”这个单一资源，事务间不存在交叉等待链。但代价也很直接：哪怕两个UPDATE改的是完全不同的行，只要操作同一张表，就得排队。

mysql如何实现商品库存管理系统_mysql数据表与操作流程

2026年2月24日

直接 UPDATE goods SET stock = stock – 1 WHERE id = 123 是危险的——并发下单时可能超卖。正确做法是在 SQL 层就拦截非法扣减：UPDATE goods SET stock = stock – 1 WHERE id = 123 AND stock >= 1;执行后检查 ROW_COUNT() 返回值：为 0 表示库存不足或商品不存在，不是靠应用层查一遍再扣，那会引入竞态。

mysql触发器会影响SQL执行计划吗_mysql执行计划优化

2026年2月24日

MySQL 的 EXPLAIN 或 EXPLAIN FORMAT=JSON 输出只反映当前 SQL 语句本身的访问路径、连接顺序、索引选择等，**不会把触发器里的语句纳入执行计划分析范围**。触发器逻辑在语句执行完成（或回滚前）才被调用，属于“事后动作”，优化器根本看不到它。

mysql如何在高并发下优化查询_mysql性能调优方法

2026年2月23日

加了索引却没提速，常见原因是查询条件没走索引。比如对 user_name 建了索引，但写成 WHERE LOWER(user_name) = ‘alice’，MySQL 无法使用索引做前缀匹配；又或者用了 LIKE ‘%abc’ 这种左模糊，索引失效。