MYSQL的案例问题 - 腾讯云开发者社区 - 腾讯云

开发者社区

文档建议反馈控制台

文章/答案/技术大牛

发布

mysql空间问题案例分享

可行性较高, 先查询下我这里没得碎片问题, 实际场景可能还有碎片问题,需要注意下.处理过程查询数据量我们登录数据库查询下, 数据量和索引量的比较 SELECT ROUND(SUM(data_length...那我们就来统计下这部分空间有多大吧.我们可以查询mysql.innodb_index_stats表看对应索引的大小, 虽然是统计信息, 但误差不会太大.主键索引不算在索引大小里面, 而是算在数据大小里面的我们查询...我们回到刚才的问题: 查看未使用的索引的大小.-- 查询未使用的索引的大小明细SELECT a.object_schema, a.object_name, a.index_name,...答:不会, 甚至会减少, 因为没得索引的时候, mysql会自动新增个rowid来作为主键, 而人工指定主键的话, 就不会有这个rowid字段, 所以空间就会减少下来.然后将上面的结果发给开发,让他们去做即可....啰嗦一句再啰嗦一句, 上面的mysql.innodb_index_stats中的信息我们我们也可以使用ibd2sql_web去验证.

4852 0

MySQL案例：count(*)和count(1)的效率问题

前言相信大多数DBA都看见过这样一条SQL优化原则：用count(1)替换count(*)；相信也有不少DBA因这个问题被开发diss过，用count(*)非常慢，应该用count(1)，然后改用count...（1）首先看看执行计划，均走的是k_1索引 mysql> explain select count(*) from sbtest1; +----+-------------+---------+----...实例(避免buffer pool的干扰)，执行count(*)，查看profile，物理读为269008 mysql> set profiling=1; Query OK, 0 rows affected...实例(避免buffer pool的干扰)，执行count(1)，查看profile，物理读也为269008 mysql> set profiling=1; Query OK, 0 rows affected...总结 count(*)和count(1)的执行效率，是一样的；网上流传的一些优化原则，已经是不适用于当前版本，要注意及时更新自己的知识库。

4.1K23 4

您找到你想要的搜索结果了吗？

是的

没有找到

MySQL 案例：自增列的空洞问题与“小”BUG

前言在 MySQL 的常见规范里面，每个表都要设置主键，一般来说都会推荐自增列作为主键，这和 MySQL 属于聚簇索引表有关，顺序增长的主键比较合适。而自增列中比较常遇见的问题就是自增列的空洞。...空洞问题问题介绍自增列的空洞一般指的就是自增列不是连续增长，中间出现一些数值上的断层。...问题的避免如何避免这个问题，涉及到 MySQL 业务实际使用的 insert 语句的类型，这里推荐阅读(官方文档)，里面有详细的分析和场景解析。...另外一种问题场景就是 MySQL 自身各个表之间有外键关系，但是没有建立外键约束，也会遇到类似的问题。...当然，腾讯云数据库 MySQL 也修复了这个问题，可以放心使用~ 总结一下自增列虽然已经长时间，大范围的使用过了，但是也要注意这类技术可能会存在一些隐藏的问题，防微杜渐，保障业务安全运行是 DBA 应尽的职责

2.5K10 0

MySQL案例：一个实例无法启动的问题分析

log 2021-01-06 13:23:51 20464 [ERROR] Aborting （2）看到上述报错后，当然就应该想到，检查下my.cnf配置是否正确、日志目录和权限是否正确，但排查并未发现问题...mysql 7492941 Jan 6 13:23 VM_58_10_centos.err （3）报错有一个非常奇怪的点，file 'something is definitely wrong...这里需要知道的是，mysql-bin.index记录了binlog相关信息，MySQL实例启动时需要读取该文件获取信息；那接下来就检查一下该文件，发现果然有问题，mysql-bin.index后半部分错误写入了错误日志的内容...mysqld 总结至此，问题得到解决，至于为什么错误日志内容会写入到mysql-bin.index，个人怀疑是宕机导致文件错乱(该宿主机上的其他虚拟机有出现文件系统损坏的情况)；最后，还是得强调一下...，生产系统还是得重视起来，备份、高可用、容灾都是不可或缺的。

1.4K11 0

MySQL 5.5迁移到5.7的性能问题排查案例

最近和同事排查了一个MySQL的SQL性能问题。...问题的背景是有一个业务的数据库从MySQL 5.5迁移到了MySQL 5.7，原来在5.5中有一个SQL秒级就能完成，但是在5.7版本中执行时间长了好多，业务也产生了延迟。...按道理5.7的功能和改进更多，比5.5要更稳定，出现这样的问题，其实是比较奇怪的，从我们的初步理解来看，方向应该是优化器参数的影响。...1.搭建MySQL 5.5和MySQL 5.7的测试环境 2.把相关表的数据导入两个环境 3.模拟测试指定的SQL语句，在MySQL 5.7中查看指定语句的执行计划。...2.尽可能从MySQL 5.7的一些新特性方向进行排查，是否有一些其他的特性会导致这类问题，比如半同步，比如派生表等，不能单纯从优化器开关入手。

1.2K2 0

MySQL案例：not null和default的一个小问题

前言前几天，有位童鞋咨询我一个问题，如果表新增一个not null字段、不指定default，那么这个操作能成功吗？当时我不假思索地回答会直接报错，结果当然就是被啪啪打脸。...后续回顾这个问题，做出此错误回答的原因有那么几个：一是not null和不指定default两者本身是冲突的；二是Oracle相关经验告诉我会报错；三是MySQL开发规范一般要求指定default；接下来我们详细记录一下这个案例...Oracle是如何处理的？首先，我们看一下Oracle是如何处理这种情况的。...MySQL是如何处理的？看完了Oracle，我们再来看一下MySQL是如何处理的。...MySQL开发规范一般要求指定default 总结对于表新增not null字段、不指定default的处理方式，Oracle和MySQL是不一样的，具体总体如下：（1）对于Oracle而言，如果表为空

7.6K6 0

MySQL案例：一个有趣的慢查询问题分析

前言前几天，有位客户提了一个慢查询问题，需要这边帮忙分析一下；整个排查过程还是非常有趣，涉及到一些值得关注的知识点，因此在这里记录一下。...idx_order_no_status，不存在问题 image.png （4）其实这个时候，我们会怀疑，当时走的执行计划究竟是什么样的？...MySQL没有类似Oracle存储ASH和历史执行计划等信息，因此没有办法直接定位，但我们可以通过其它方式来排查；这里需要我们了解以下几个知识点(在问题排查中，有些知识点也是有些模糊，后面会通过实验进行验证...日志中，没有发现该order_no对应的修改记录，这可以说明该SQL是没有成功执行的；排查到这里，问题就清晰了，随后找客户确认应用超时时间设置是30s，整个事情也就可以串起来了 image.png （9...mysql> begin; Query OK, 0 rows affected (0.00 sec) mysql> insert into sbtest9 select * from sbtest1

3.5K13 0

线上的MySQL优化案例

线上的SQL优化案例（一）今天上班的时候，业务方询问了一个问题，说是某一服务每次在查询的时候会有0.5s的延迟，让DBA帮忙查一查到底是什么原因，听到0.5s的这个数字的时候，我感觉问题倒不是很严重...，我解决这个问题的方法如下： 1、先查看了一下慢日志中的内容，发现慢日志中没有具体的记录。...这个问题比较好解决，其实他的本质是设定的慢日志的阈值是1s，只有超过1s的SQL语句才会被记录，这里我把参数long_query_time的值设置成为0.4，这样，就可以把查询超过0.4s的SQL都记录到慢日志里面了...这个时候，我已经开始怀疑这个表的索引创建的是否有问题了，于是首先查看了一眼表中的数据，看看appid的值都包含哪些吧。...10005，而accounttype的值也只包含数字1，而accountid和uid的值包含5w左右，这样问题已经有点明确了。

1.4K2 0

MySQL案例：一次单核CPU占用过高问题的处理

客户现场反馈，top的检查结果中，一个CPU的占用一直是100%。实际上现场有4个CPU，而且这个服务器是MySQL专属服务器。...我的第一反应是io_thread一类的参数设置有问题，检查以后发现read和write的thread设置都是4，这和CPU数一致，因此可以断定这并不是单颗CPU占用过高的问题。...接下来需要确认MySQL究竟有没有利用到多核CPU，这个时候需要的工具叫做pidstat，命令如下： pidstat -u -t -p 18158 得到的结果如下图所示：可以看出其实mysqld是可以利用到多核...CPU的，那么此时可以得到一个推断：某个CPU上做的事情太占资源了一般这种最占资源的工作一定会在INNODB_TRX里留下一些端倪，因此检查一下：反复的检查TRX，发现mysql在不停的执行这个...DBA掌握多少种检查问题的手段，DBA面对问题时能不能第一时间找准方向，这都是经验和功力的展现。

1.2K2 0

mysql优化案例

今天发现网站页面打开非常慢，对处理过程简单记录了一下找问题首先登录服务器使用 top 查看当前进程信息，发现排名第一的是 mysql，占用 cpu 达到了 100% 以上，这就明确了是 mysql...的问题登录 mysql，使用 show processlist 查看下当前执行状态，发现了大量 LOCK 操作，也有多个 Copying to tmp table 的操作，说明有 sql 出现了问题，...操作过于复杂，对临时表使用频繁，把其他操作阻塞了解决找到了问题后，把处理方向确定为检查和修改配置、sql优化（1）修改mysql配置临时表既然涉及了到了临时表，就先查看下目前临时表的信息查看临时表的使用状态...threads_created 的值过大，表明MySQL服务器一直在创建线程查看当前值 show variables like 'thread_cache_size'; 此参数需要调高打开表数量查看打开表的情况...，对其进行 explain 和 profile 分析进行索引优化，把复杂的sql 根据业务拆分为多个小的sql 以上过程完成后，mysql已经恢复正常状态，后期再对其他sql进行优化和缓存处理

1.1K5 0

案例：推进GTID解决MySQL主主不同步问题

之前文章介绍过MySQL修改lower_case_table_names参数，如果之前大写存储的表将无法识别，需要特殊处理。...y 而且后续根据故障现象推测：操作人员最初只在一个主节点做了这样的操作，随后在这个主节点执行了删除数据库的动作，最后又建立了新的数据库重新建表，最终才发现另一个主节点已经不同步了，尝试自己无法解决后，上报了故障给客户...Master_UUID: 08c887bf-98ab-11ea-b70c-080027c2997a Master_Info_File: mysql.slave_master_info...是连续的。...test库记得要处理掉，不然以后还会有问题隐患。

1.1K3 0

MySQL实例crash的案例分析

【问题描述】我们生产环境有一组集群的多台MySQL服务器(MySQL 5.6.21)，不定期的会crash，但error log中只记录了重启信息，未记录crash时的堆栈： mysqld_safe...【排查思路】由于日志中未记录有价值的信息。为定位crash的原因，首先开启mysql core dump的功能。...2、修改系统参数，配置suid_dumpable echo 1 >/proc/sys/fs/suid_dumpable 3、重启mysql服务，配置生效【问题分析】开启core dump后，服务器再次...在网上搜索类似的问题，有了进一步的进展，基本确定了这个问题是bug导致如下Mysql的bug report中讲述了类似问题 https://bugs.mysql.com/bug.php?...后面了解到这是MySQL的一个bug，在MySQL 5.6.35版本后已修复。这个bug在应用端与数据库建立大量的连接时，更容易触发。

1.4K1 0

MySQL 案例：“丢失数据”的谜题

登录到数据库之后，发现业务库是存在的，结合用户的反馈：“业务库不见了”，初步判断是业务账号没有权限，用show grants查看之后，发现业务账号的权限只有 USAGE，类似如下效果： mysql> show...事后排查发现最初的授权操作发生在一个其他的同名账号上，类似于： mysql> show grants; +------------------------------------------------...> 拓展一下对于“丢失数据”这个现象来看，如果是“丢失”了整个库级别的数据，但是数据库本身又一切正常的话，其实有蛮大的可能性和这个案例是一样的问题：权限错误。...严格的来说，这一类问题也有可能是权限错误引起的，因为 MySQL 的权限控制确实可以做到表和列级别，只是现实中一般不会用到。...总结一下遇到这一类问题时，可以先花一点观察一下问题的现象，可能只需要几秒钟的时间重新授权就解决这类“丢失数据”的非常紧急且非常严重问题。

4.5K14 2

MySQL覆盖索引的使用案例

在使用覆盖索引时，执行计划的Extra字段中有Using index的信息，下面是一个SQL语句的执行计划： mysql>explain select customer_id,inventory_id,...由于二级索引实质上都包含主键，因此如果再加上主键，一样可以使用覆盖索引，下面是在输出字段中加上主键字段的SQL语句的执行计划： mysql>explain select rental_id,customer_id...但如果要访问的字段不在这个索引中，则还需要访问表，如果在上面的查询字段中再增加任意一个其他字段就不能使用覆盖索引了，例如下面的SQL语句将无法使用覆盖索引： mysql>explain select *...但可以对这个SQL语句进行改写，先用一个可以使用覆盖索引的子查询查询出主键，再通过主键查找相应的记录，这种方法称之为延迟关联（deferred join），改写后的SQL语句执行计划如下： mysql>...延迟关联的方法在分页查询中对效率的提高很明显，例如下面的SQL语句进行排序后从1000行开始查询5行，它的执行计划如下： mysql> explain analyze select * from rental

1331 0

MySQL使用问题_mysql的使用

MySQL常见的性能瓶颈一般都是出现在CPU和I/O上，即在数据装入内存中或磁盘上读取数据时，CPU发生了饱和或装入数据过大，内存容量不足，磁盘I/O性能被限制。...通过Explain可以获得表的读取顺序和引用数据读取操作的基本类型可使用的索引以及实际使用的索引优化器的查询行数使用方法： Explain + SQL语句可得到的信息参数意义...：唯一性索引扫描，对每个索引键表中只有一条相对应的记录，也就是主键或唯一索引和他们对应的数据这样的情况 ref：非唯一性索引扫描，即索引查找出对应多个符合条件的数据 range：只检索给定范围的行...额外的事务，是比较重要的用于分析检索效率的信息，包含以下： Using filesort：MySQL使用了一个外部的索引排序：“文件排序”，表示无法使用表内的索引顺序进行读取 Using...temporary：使用了临时表，该信息通常在使用了排序或分组查询时出现，MySQL使用了临时表来存储order by和group by需要进行排序的查询结果 Using index：在select操作中使用了覆盖索引

2.2K7 0

MySQL优化案例分享

临近十一，国庆放假的同时，往往会伴随着国庆期间业务要上相关的活动，那么今天就分享一个今年五一前夕（4月30日）上新活动中遇到的一个性能问题；问题背景五一前夕（4月30日）中午频繁的收到业务慢查询的告警...排查过程查看mysql实例监控，发现CPU在不断增长，系统的负载也在不断的增加查看慢查询日志，发现有一个update操作的慢查询，执行时间在50s多，而且锁的时间48s多，经过和业务人员沟通...，由于五一活动游戏开赛，所以出现业务量的突增，那么接下来我们来分析下慢SQL的问题，下面是慢查询日志中的记录： # Time: 2021-04-30T06:32:37.832446Z # User@Host...按道理来说，update操作不应该会很慢，那么接下来，我们看一下sql语句的执行计划： mysql>explain UPDATE dic_match_signup_userinfo_7 SET state...从字面意义来上intersect就是交集的意思。虽然性能上没多少影响，但比较好奇，在理解当中MySQL知识体系中是没有交集语法。

9700 0

mysql遇到的问题

查询结果 2.mysql修改表结构报 1833错误先将外键配置删除，再更新表结构，然后再把外键添加回来即可这也说明，建立关联前，要把表结构设计好，检查好，，， 3.mysql防止插入重复由于我插入的是关联表...INSERT `data`(did,param1,param2,param3,param4) SELECT 5,23,44,1,1 FROM device WHERE device.id=5 5.MySQL...1215 Cannot add foreign key constraint 错误解决办法外键数据格式和相对于的另一个表的主键格式不一样导致的，改成相同的格式和length即可。。。

8372 0

MySQL优化案例(二）

这是学习笔记的第 1979 篇文章近期收到慢日志监控报警，在慢日志平台查看，主要瓶颈在于几条创建临时表的SQL语句，占用了大量的临时空间，需要优化。 ?...rw-r----- 1 mysql mysql 2818572288 May 13 14:41 ibdata1 -rw-r----- 1 mysql mysql 158792155136 May 13...14:40 ibtmp1 drwxr-x--- 2 mysql mysql 4096 Apr 18 2018 infra drwxr-x--- 2 mysql mysql...SQL层优化 SQL语句的优化分析发现，基于json类型的解析差异和字符类型存在较大的性能差异，建议对json的子查询创建临时表。...profile的对比方式来分析： mysql> show profile cpu for query 1; +--------------------+----------+----------+--

7942 0

MySQL死锁案例分析

本文针对上一篇《MySQL优化案例分享》文章中提到的线上业务产生的一个死锁问题进行展开讨论，主要针对两个update操作导致的死锁的场景，借此机会正好总结下MySQL锁及分析下产生死锁的原因和解决方案；...首先，针对MySQL中提供的锁种类做一个简单的总结，关于更多MySQL锁相关的内容可参考官方文档； MySQL InnoDB存储引擎提供了如下几种锁： 1、共享/排他锁（S/X锁）共享锁（S Lock...案例分析 MySQL版本：MySQL 5.7 隔离级别：RC Session1 Session2 T1 begin;select * from locktest where name=’test’ lock...两个事务同时对一条数据进行更新的时候（可能并发也可能非并发），两个update语句都拿到了S锁，但是升级X锁的时候，出现问题，因为S锁升级X锁，在隔离级别是RC的情况下，必须等所有的S锁释放才能S锁升X...MySQL之上加了一层redis缓存锁，防止多个事务同时更新一个数据，如果有其他的解决方法，欢迎大家留言讨论；

2.7K2 0

MySQL中的全表扫描案例

MySQL中的全表扫描案例这两天看到了两种可能会导致全表扫描的sql，这里给大家看一下，希望可以避免踩坑：情况1：强制类型转换的情况下，不会使用索引，会走全表扫描。...varchar类型的字段score是一个索引，而id是主键。...然后我们给这个表里面插入一些数据，插入数据之后的表如下： mysql：yeyztest 21:43:12>>select * from test; +----+------+-------+ | id...varchar类型的值，那么结果中扫描的行数rows就是1，而当我们使用的是整数值10的时候，扫描行数变为了7，证明，如果出现了强制类型转换，则会导致索引失效。...=作为条件的时候，扫描的行数是表的总记录行数。因此如果想要使用索引，我们就不能使用反向匹配规则。情况3：某些or值条件可能导致全表扫描。

3.2K2 0

点击加载更多

相关资讯

热门标签

活动推荐

运营活动

活动名称

广告关闭