记录一次数据库慢sql
发表于|更新于|技术手册
|浏览量:
起因
由于数据库系统的查询一直在使用es监控，某一天收到一条报警记录
在遇到这个告警的时候，还存在一些疑问，这么简单的sql居然会报慢查询。
经过
经过查看数据库数据，发现由于topic_type只有1和0两个状态，就未给它设置索引
结果
经过查看该表有数据40+W，在sql中topic_type=1的数据比formid的数据多的多，导致了查询时导致了慢sql
后记
修改了sql的查询顺序，发现再也没有慢日志产生，由此得出结论：
- 数据库语句查询条件并非并行，而是有先后关系，所以一定要注意查询语句的先后关系，范围小的先放前面
- 该加索引就必须加索引，数据库性能达到瓶颈能导致整个系统崩溃
- 微服务环境下，不仅要分库分表，还需要将不同服务的数据库分别部署，增强容灾性，一旦某个库达到瓶颈，后果会形成链式反应
文章作者: Jack
版权声明: 本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 星空！
相关推荐
2018-10-14
mysql中间件-Mycat
前言因业务需要，给mysql做了主备，然后准备使用数据库中间件来进行读写分离和分片。 学习过程学习过程中使用了三台服务器，一主两备，此处只用一主一备参与中间件的试用。 集群组成如下： 角色 主机名 主机IP master liunian1 192.168.1.1 slave liunian2 192.168.1.2 slave liunian3 192.168.1.3 先配置mycat配置文件schema.xml 123456789101112131415161718<?xml version="1.0"?><!DOCTYPE mycat:schema SYSTEM "schema.dtd"><mycat:schema xmlns:mycat="http://io.mycat/"> <!-...
2020-04-01
线上事故记录-docker与Java的恩怨情仇
起因上周五新建了一个项目，在开发完成后，和运维沟通准备上到生产环境中，套用了现有服务的通用启动命名行： 1java -jar Xms3072m -Xmx8192m app.jar & 2>1 然后一切准备就绪，jenkins打包一切顺利，然后顺利部署到生产环境，由于前端项目暂未部署，k8s使用的内网集群通信，暂时没有办法调用接口进行服务部署成功验证，但是在测试环境进行了充分测试，一切OK 。 在周五即将下班的时候，运维给我这边发消息，说我的服务没有部署成功,然后把日志给我发了过来，内容大致如下： 服务启动日志并没有出现JVM的字样，日志一直没有打下去 经过经过排查，发现服务没启动完成，突然想起来前几天碰到一个问题，就是当内存不足时，docker会自动kill掉容器。最终确认是服务的相关资源配置没给到位，被docker给强制关闭了。 询问运维给的相关配置内存为1G,但是我启动时设置的最小初始化内存为3G，此时被k8s认为资源不足，给kill掉，导致服务无限重启 结果调整了启动参数为1G，服务顺利启动。 反思该问题其实是一个非常简单的启动参数设置不合理导致的服务无法...
2018-10-14
sql之left join、right join、inner join的区别
left join(左联接) 返回包括左表中的所有记录和右表中联结字段相等的记录right join(右联接) 返回包括右表中的所有记录和左表中联结字段相等的记录inner join(等值连接) 只返回两个表中联结字段相等的行 举例如下：表A记录如下： 123456aID aNum1 a200501112 a200501123 a200501134 a200501145 a20050115 表B记录如下: 123456bID bName1 20060324012 20060324023 20060324034 20060324048 2006032408 1.left joinsql语句如下: 123select * from Aleft join B on A.aID = B.bID 结果如下: 123456aID aNum bID bName1 a20050111 1 20060324012 a20050112 2 ...
2018-10-14
Docker备份Mysql数据库
1.备份数据库脚本vi dump.sh 123456789101112mysql=`docker ps|grep mysql | awk '{print $1}'`backDate=`date +%F_%H-%M-%S`if [ ! -e "/data/backup/$backDate" ]; then mkdir -p /data/backup/$backDatefiecho $mysqldataBases="teaching"; //备份数据库名称for dataname in ${dataBases}do docker exec -i $mysql mysqldump -h localhost --opt -u root --password=mypassword --default-character-set=utf8 --hex-blob $dataname > /data/backup/$backDate/$dataname...
2018-10-12
mysql-slave踩坑日记
晚上闲来无事，想找点事做于是手动删除了一些无用的数据库，手贱的是在从库里面删除了 然后，在主库里面也进行该数据库删除，发现未手动删除的从库正常执行了binlog日志中的sql语句 一段时间后，问题出现了自己手动在主库里插入一条语句，发现两个备库只有一个备库更新了最新的数据，手动删除数据库的那个从库并未更新语句 接下来，查询从库mysql日志 发现 122018-08-19T19:27:04.704407+08:00 6 [ERROR] Slave SQL for channel '': Error 'Can't drop database 'jeewx-h5'; database doesn't exist' on query. Default database: 'jeewx-h5'. Query: 'DROP DATABASE `jeewx-h5`', Error_code: 10082018-08-19T19:27:04.704429+08:00 6 [W...
2018-12-08
线上long型数据丢失精度问题
前因在dev和qa环境正常获取到用户的userId,dev和qa环境的userId长度都不长，通过userId查询数据，显示数据完全正常。 但是上线之后，很快有运营反馈使用userId查询不出结果，经过验证发现确实这样，开始排查问题 排查过程由于我们项目后端使用的是接口层与业务层隔离的架构，所以先在业务层加上日志，拿到日志之后和web层获取到的数据进行对比。对比结果发现该userId在较长时候确实出现了不一致的情况，但是业务层的数据和数据库中的数据完全一致，哪一步操作导致精度丢失了呢？ 进一步排查，在接口层打输入输出日志，发现接口层的输入输出与业务层完全一致，在此种情形下，我们有点摸不着头脑，还以为是我们读错了库的原因。 验证数据库后发现，库没读错，数据完全和库一致，那只能是传输过程中出现问题了。 我们使用的是chrome浏览器，接口层数据是直接使用network扩展里面的preview，经过仔细排查发现，preview的数据和response里面的数据不一致，至此问题找到： 前端接受json数据时，精度丢失。 解决方案因为字段固定的缘故，我们不准备从后端进行更改，准备web层直...
评论