- 综合排序
- 最热优先
- 最新优先
- 来自专栏运维研习社
MySQL多实例踩坑
最近由于业务要求，需要在服务器添加一个mysql实例，遇到个坑，分享下 安装mysql不必多说了，多实例肯定是下载二进制包安装，这个网上很多教程，我就不罗嗦了 正常安装mysql实例，在解压的二进制包里面 它里面会带有一些推荐的配置文件和启动脚本，单实例mysql.server，多实例mysqld_multi.server，通过修改basedir和datadir，就可以用这两个脚本来管理mysql服务 正常情况下 读取配置文件和启动的一些原理整理如下： MySQL读取配置文件的顺序是： /etc/my.cnf > /etc/mysql/my.cnf > /usr/etc/my.cnf > ~/.my.cnf 这个顺序可以通过命令来验证 /mysqld start这样的方式启动的时候，其实是使用了mysql.server这个脚本，这个脚本默认会调用mysqld_safe来启动mysqld，所以通常我们启动mysql之后查看进程的时候会发现有 接着通过分析启动脚本看下MySQL启动原理 默认的mysql的服务启动程序是mysql.server，就是我上面说得那个目录下，mysql.server程序主要是会用到两个程序和一个函数，分别是my_print_defaults
1.6K20发布于 2020-06-15 - 来自专栏快乐阿超
mysql大小写踩坑
设置了mysqld下的配置 [mysqld] lower_case_table_names = 1 lower_case_table_names的官方文档： https://dev.mysql.com/ 服务不是mysqld而是mysql，下面是ubuntu的三种重启方式 # 重启服务 service mysql restart; # 重启系统服务 systemctl restart mysql # 重启 mysql，请确认路径 /etc/init.d/mysql restart 修改后可以用这三个sql查询是否生效 select @@lower_case_table_names; +---------- 翻译过来就是说Linux或者其他类似Unix的系统，不支持设置为2[1]，mysql服务端会强制使用0代替 那么这么多表名，一个一个改不是很麻烦？ qrtz_triggers; 如果不知道这些表是怎么来的，可以查看这篇quartz 结束后，我们配置的lower_case_table_names = 1即可生效，可以用show tables;检查一下 好坑，
2.2K20编辑于 2022-08-21 - 来自专栏数据分析
从MySQL迁移PostgreSQL：算法团队踩过的7个坑
坑1：JSON字段的"静默数据损坏"1.1 问题现象与影响迁移后第二天，推荐系统的线上日志突然爆发大量JSON parsing error。 坑4：字符集与排序规则的隐藏炸弹4.1 问题现象与影响迁移后第五天，用户反馈搜索结果"全乱了"。排查发现，LIKE '%用户%'查询在PostgreSQL中返回的结果集与MySQL完全不同。 坑5：窗口函数性能"反向优化"5.1 问题现象与影响迁移后第七天，特征工程团队报告核心特征计算任务耗时从MySQL的45分钟增加到PostgreSQL的2.5小时，涨幅达233%。 坑6：VACUUM与MVCC的"磁盘黑洞"6.1 问题现象与影响迁移后第十天，监控告警磁盘空间使用率从60%暴涨至95%，每天增长约50GB。业务写入量正常，没有大量新增数据。 坑7：GIS函数差异导致位置计算错误7.1 问题现象与影响迁移后第十二天，基于地理位置的推荐算法突然失效。用户反馈"附近商家"功能返回的商家距离偏差在500米至2公里之间。
66710编辑于 2025-12-11 - 来自专栏Postgresql源码分析
Mysql悲观锁踩坑测试
mysql for update 今天遇到一个高并发悲观锁的问题，活跃连接堆积恶性循环最后DB卡死了。做下测试总结。看看这类SQL能扛多少，以后遇到问题心里也有底了。 20) NOT NULL, PRIMARY KEY (`id`), KEY(`c1`), KEY(`c2`,`c3`,`c6`), KEY(`c4`,`c5`) ); mysql tables in use 1, locked 1 LOCK WAIT 2 lock struct(s), heap size 1136, 2 row lock(s) MySQL thread id tables in use 1, locked 1 LOCK WAIT 2 lock struct(s), heap size 1136, 3 row lock(s) MySQL thread id tables in use 1, locked 1 LOCK WAIT 2 lock struct(s), heap size 1136, 4 row lock(s) MySQL thread id
64120编辑于 2022-05-12 - 来自专栏企鹅号快讯
MySQL表设计踩过的坑！
希望我能说说我在数据库表设计时踩过的坑。那么，我们今天就来聊聊我在数据库表设计时踩过的坑，以及现在对数据库表设计的一点建议。希望能够帮助到你。 主外键字段类型不一致 主外键类型不一致，说起来，你可能会不相信，但在数据库表设计时，稍不留神，就不一致，埋下隐式类型转换的坑。 你可能觉得你不可能发生这样的错误，说出来也不怕你笑话，我就踩过好几次这样的坑，到最后发现慢SQL了，才发现自己中了这样的坑！！！ 索引怎么加，索引重不重要，可以查看《写会MySQL索引》一文进行查看！唉，我就吃过不少没加索引或忘记添加索引的亏，记忆犹新！！！ 上面是我数据库表设计时，遇到踩过坑以后的经验之谈。有些坑当时还真花了不少时间来填补。记录在这里，如果能帮助到你，那就太好了！
1.3K80发布于 2018-02-07 - 来自专栏程序员的成长之路
MySQL Online DDL 原理和踩坑
导读：MySQL 的 DDL(Data Definition Language) 包括增减字段、增减索引等操作。 在 MySQL 5.6 之前，MySQL 的 DDL 操作会按照原来的表复制一份，并做相应的修改。 因此，MySQL 5.6 增加了 Online DDL，允许在不中断数据库服务的情况下进行 DDL 操作。 用法 ? 另外也可以设置 ALGORITHEM=DAFAULT，让 MySQL 以尽量保证 DML 并发操作的原则选择执行方式。 踩坑 前面提到 Online DDL 执行过程中需要获取 MDL，MDL (metadata lock) 是 MySQL 5.5 引入的表级锁，在访问一个表的时候会被自动加上，以保证读写的正确性。
2.2K31发布于 2021-07-13 - 来自专栏wayn的程序开发
MySQL datetime 类型精度设置踩坑
本文也是作者实际踩坑后结合实际案例，深入剖析 datetime 类型的精度问题，并提供解决方案和最佳实践。 1.2 四舍五入与进位问题 当插入的毫秒值超过 0.5 秒时，MySQL 会自动进位。 二、问题根源分析 2.1 MySQL 版本差异 MySQL 5.6.4 之前：datetime 类型不支持毫秒精度，插入值的小数部分会被直接丢弃或四舍五入。 (3) -- 精确到毫秒 ); 2.2 客户端工具的显示误导 某些常用的客户端工具（如 Navicat）在设计表时默认将 datetime 的精度默认设置为 0，稍不注意就会踩坑。 在跨数据库迁移（如 MySQL 到 TiDB）时，若未统一时区设置，可能导致时间解析错误。
2.1K10编辑于 2025-05-26 - 来自专栏码农架构
MySQL Online DDL 原理和踩坑
导读：MySQL 的 DDL(Data Definition Language) 包括增减字段、增减索引等操作。 在 MySQL 5.6 之前，MySQL 的 DDL 操作会按照原来的表复制一份，并做相应的修改。 因此，MySQL 5.6 增加了 Online DDL，允许在不中断数据库服务的情况下进行 DDL 操作。 另外也可以设置 ALGORITHEM=DAFAULT，让 MySQL 以尽量保证 DML 并发操作的原则选择执行方式。 踩坑 前面提到 Online DDL 执行过程中需要获取 MDL，MDL (metadata lock) 是 MySQL 5.5 引入的表级锁，在访问一个表的时候会被自动加上，以保证读写的正确性。
1.1K30发布于 2021-07-08 - 来自专栏凝神长老和他的朋友们
nuxt使用antv-l7踩坑
nuxt.js 下使用 antv-l7 实在是有太多的坑了，官方文档也不是很全，只能不断摸索和尝试，下面我把这些坑记录下来，也许能帮到你。 js import Vue from 'vue' const l7 = require('@antv/l7') const l7maps = require('@antv/l7-maps') Vue.prototype $l7 = l7 Vue.prototype. $l7 的方式使用 const { Scene, Popup } = this.$l7 const { GaodeMap, Mapbox } = this. $l7maps 地图不能重复渲染，会卡死 这个坑出现的原因还没有找到，怀疑是 antv-l7 这个库在实现时有问题，也可能是与 nuxt 的某种机制冲突，因为好像单独用的时候是没问题的 问题表现如下：
2.6K30发布于 2020-12-29 - 来自专栏blog(为什么会重名，真的醉了)
PHP连接MySQL-踩坑总结
文章目录 写在前面 mysqli扩展 MySQL权限 测试 写在前面 ---- 版本迭代，网上很多解决方法都失效了，在此记录一下。 mysqli_connect() in D:\tools\Apache24\htdocs\UIUE\index.php:6 Stack trace: #0 {main} thrown in PHP7之后就移除了 mysql扩展（可以自己打补丁 ），而是推荐使用mysqli扩展和pdo_mysql。 $link) { echo "Error: Unable to connect to MySQL." . > 至此PHP就成功连接MySQL了o(*￣▽￣*)o，mysqli相关用法可查官方文档。
3.5K30发布于 2021-09-14 - 来自专栏做数据的二号姬
踩坑经验 | Mysql导入emoji报错
踩坑经验 | Mysql导入emoji报错 上周遇到了中文长度的问题之后，就想起了很久之前遇到的这个问题，也是一个和长度相关的问题。 LEARN MORE 图片由360鸿图绘制 还是老规矩，周日不定期更新的踩坑系列。还是先介绍一下遇到这个问题的业务场景，因为时间比较久远了，很多细节已经想不起来了。 上周末的推送讲了，在mysql中，中文是占3个字节的。而emoji比较特殊，占4个字符。 根据各种资料收集的结果来看，不同版本的mysql对于设置这里是有细微的区别的。 数据处理技术分享、代码分享 周三：工作效率提升工具/技巧，办公自动化等 周四：读书笔记系列，分享读书心得和要点 周五：聊聊职场，包括但不限于求职面试 周六：随缘分享，内容不确定 周日：随缘分享一些技术踩坑经验
59820编辑于 2023-10-24 MySQL 索引失效的那些坑：从踩坑到填坑
那么，MySQL 索引到底在哪些场景下会失效呢？ 我结合自己踩过的坑，总结了一些典型的案例。下面就一一展开。 3 隐式类型转换这个坑特别隐蔽，尤其是在 字符串和数字比较 时。 7 IS NULL 和 IS NOT NULL这两个操作符有点特殊：IS NULL 在某些版本下还能用上索引IS NOT NULL 基本就和索引说拜拜了比如：SELECT * FROM user WHERE 因为 MySQL 觉得直接扫一遍比走索引还快。这种情况不是 bug，而是优化器的“聪明决定”。10 强制索引与执行计划有些时候 MySQL 的优化器并不聪明，选错了索引。 总结索引是 MySQL 提升性能的利器，但稍不注意，它就可能失效。
36510编辑于 2025-09-06- 来自专栏why技术
踩坑了，又踩坑了！
踩坑了啊，又踩坑了啊！ 这次踩到一个特别无语的常识坑。知道真相的那一刻，人就是整个麻掉。 他给的其中一个超链接是 Java 语言规范： https://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.2.3 Java 语言规范表示
63220编辑于 2022-11-01 - 来自专栏java_joseph
docker-mysql8.0踩坑敏感问题
分享下docker部署mysql8.0踩坑经历 在一次项目中想用docker部署mysql8.0出现了这种问题 数据库是有这个表的，但是项目使用的时候，就出现了这样的问题，因为编码中大写，导致请求到mysql 这是docker部署mysql的一个坑， 这里给大家提供一个标准的docker部署mysql8.0的正确流程。 解决了大小写敏感问题 还踩坑你打我 #opt目录是Linux提供我们扩展的目录，可以存放用户需求的文件 mkdir -p /opt/datas/docker/mysql/conf mkdir -p /opt 3306:3306 \ -v /opt/datas/docker/mysql/conf/my.cnf:/etc/mysql/my.cnf \ -v /opt/datas/docker/mysql/data :/var/lib/mysql \ -e MYSQL_ROOT_PASSWORD=<your password> \ -e lower_case_table_names=1 \ -d mysql:8.0
1K20编辑于 2023-08-02 - 来自专栏码海
这个 MySQL bug 99% 的人会踩坑!
order by id asc limit 1 可以看到它的 possible_keys（此 SQL 可能涉及到的索引） 是 idx_uid_stat，但实际上（key）用的却是全表扫描 我们知道 MySQL 为了查看 MySQL 优化器为啥选择了全表扫描，我打开了 optimizer_trace 来一探究竟 画外音：在MySQL 5.6 及之后的版本中，我们可以使用 optimizer trace 功能查看优化器生成执行计划的整个过程 information_schema.OPTIMIZER_TRACE; // 查看执行计划表 SET optimizer_trace="enabled=off"; // 关闭 optimizer_trace MySQL 这个 bug 最早追溯到 2014 年，不少人都呼吁官方及时修正这个bug，可能是实现比较困难，直到 MySQL 5.7，8.0 都还没解决，所以在官方修复前我们要尽量避免这种写法，如果一定要用这种写法 SQL 虽然是按 id 排序的，但在 id 上作了加法这样耗时的操作(虽然只是加个无用的 0，但足以骗过优化器)，优化器认为此时基于全表扫描会更耗性能，于是会选择基于成本大小的方式来选择索引 巨人的肩膀 mysql
1K21发布于 2021-09-28 - 来自专栏编程小白狼
MySQL 中最容易踩的 8 个坑 ！
在使用 MySQL 进行数据库管理与开发的过程中，即便经验丰富的开发者，也难免会踏入一些隐藏的“陷阱”。 以下便是 MySQL 中最为常见且容易踩中的 8 个坑，了解它们能帮助我们更高效、稳定地使用这一强大的数据库系统。 一、字符编码不一致导致乱码 MySQL 的字符编码设置是个精细活儿。 四、事务隔离级别设置不当引发问题 MySQL 有多种事务隔离级别（如读未提交、读已提交、可重复读、串行化），选错隔离级别会造成数据一致性、并发性能失衡。 五、隐式类型转换导致索引失效 在 WHERE 条件里，若数据类型与字段定义类型不一致，MySQL 会自动进行隐式类型转换。 总之，在 MySQL 开发运维中，避开这些“坑”需要我们对数据库原理、配置细节、SQL 编写技巧深入钻研，从编码规范、性能优化、数据一致性保障多维度考量，才能让 MySQL 稳定高效支撑业务运转。
62910编辑于 2024-12-31 - 来自专栏苏三说技术
MySQL 中最容易踩的 15 个坑 ！
在我们日常工作中，可能会经常使用MySQL数据库，因为它是开源免费的，而且性能还不错。 在国内的很多公司中，经常被使用。 但我们在MySQL使用过程中，也非常容易踩坑，不信继续往下看。 今天这篇文章重点跟大家一起聊一聊使用 MySQL 的15个坑，希望对你会有所帮助。 7 字符集设置不当 有些小伙伴，喜欢将MySQL的字符集设置成utf8。 我几年之前也喜欢这干。 但后面出现问题了，比如在用户评价输入框中，用户输入了表情符合，可能会直接导致程序保存。 下面这张图给大家列举了常见原因： 想进一步了解索引失效问题的小伙伴，可以看一下我的另一篇文章《聊聊索引失效的10种场景，太坑了》，里面有非常详细的介绍。 在MySQL中只保存最新的数据，历史数据可以迁移到归档库中。
54410编辑于 2024-11-26 - 来自专栏Android&Java技术
JDBC访问MySQL数据库踩坑
JDBC访问MySQL数据库踩坑 作为一个 Android 开发者，闲来无事，想着使用 JSP + Servlet 写一些简单的接口，然后通过前端调用接口，后端的数据库使用的是 MySQL。 1.安装MySQL 数据库 安装比较简单，打开 MySQL 官网，我们是个人使用，所以下载最新的（8.0）社区免费版即可。 安装过程中可能需要您设置管理员密码，默认账号为 root,安装完成后就可以启动 MySQL 服务了，Windows下的启动命令如下： 使用管理员权限打开Windows PowerShell 开启MySQL 服务： net start mysql80 关闭MySQL服务： net stop mysql80 2.连接MySQL服务 我们要创建并操作数据库首先要连接到数据库，连接数据的可视化工具比较多，如 Navicat 、 MySQL Workbench、 SQLyog 等，当然，如果你对 MySQL 的命令行比较熟练的话，也可以使用命令来进行相关操作，我个人比较喜欢使用 Navicat。
4.3K10发布于 2020-02-27 - 来自专栏程序员升级之路
Mysql中间件360 Atlas踩坑
最近有同事反馈一些用户在查看个人回复时，部分页取不到数据，原因是一些SQL直连Mysql有返回结果，而通过Atlas返回空，SQL如下： SELECT * FROM post_reply WHERE `
70430发布于 2020-09-11 - 来自专栏AustinDatabases
挖坑，踩坑，填坑
又到了周五的胡扯时间，今天来扯一扯坑。 最近，有一个感觉，就是一直在填坑，我想不止我一个人，不少奋战在一线的“勇士”，都在填坑。一般来说坑分两种，自己挖的，和别人挖的。 除了有多年“挖坑”，“踩坑”，“填坑”，的道行，你大约还的总结出来一套，如何来补坑的办法。 废话了这么多，下面来举个例子，最近在做多源复制的事情，而作为源头的MYSQL 数据库，是五花八门，（前些日子有一篇文章已经说了一部分了），这次的故障更是奇怪，命名已经添加了 GTID的参数，数据库也没有任何报错 在MY.CNF 中注销掉这个参数，重启动服务器 再次运行MYSQLBINLOG 解开BINLOG 后发现有错误，看了刚踩完一个坑，又来一个坑，经过查询后，提示是MYSQLBINLOG 的版本不对 ? 通过查询系统中存在三个MYSQLBINLOG ，经过逐一的测试，发现/mysql/bin/mysqlbinlog 这个才是真正可以使用的MYSQLBINLOG ，而默认键入的 mysqlbinlog
64020发布于 2019-09-30
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号