业务需要，LIKE 的时候必须使用模糊查询，我当然知道这会导致全表扫描，不过速度确实太慢了，直观感受，全表扫描不至于这么慢！
运维工作偏多一些，但是sql性能要开发人员注意 MySql性能监控 慢查询-默认1s 10s太慢了 被慢查询记录到日志 全表扫描，没建索引，因此被记录到日志 有索引，不会被记录到日志
最近在折腾把所有mysql slow query log写入到数据库中，再集中展示，向业务部门开放，也方便业务部门的同学自行查看并优化各自业务内的慢SQL。增加了定期生成报表的功能，统计最近1~2周内的慢查询数量变化情况，给业务方同学更直观的数据对比，了解最近这段时间的慢查询数量变化情况，是多了还是少了。于是有了下面这一坨SQL：
MySQL优化一般是需要索引优化、查询优化、库表结构优化三驾马车齐头并进。 本章节开始讲查询优化。 一、为什么查询速度会慢 可以把查询当作一个任务，它由一系列子任务组成，每个子任务都会消耗一定的时间。如果要优化查询，实际上是优化其子任务，要么消除其中一些子任务，要么减少子任务的执行次数，要么让子任务运行得更快。 MySQL在执行查询的时候有哪些子任务，这个是有一定的方法进行剖析的，具体方法下回单独拿一个章节来分析。 通常来说，查询的生命周期大致可以按照顺序来看：从客户端，到服务端，然后在服务器上进行解
在我们日常开发中，分页查询是必不可少的，可以说每个后端程序猿大部分时间都是CURD，所以分页的查询也接触的不少，你们都是怎么实现的呢？前不久的一段时间，我的一个同事突然找我寻求帮助，他说他写的sql查询太慢了，问我能不能帮他优化一下那条查询语句，经过一段时间的优化，我们成功的将原来8秒一条的sql成功优化到了不到一秒，然而想到知识应该学会分享，所以我今天打算写出这个优化过程，可以让更多的程序猿可以看到。
假设我们有一张数据表 employee(员工表)，该表有三个字段（列）,分别是name、age 和address。假设表employee有上万行数据(这公司还真大），现在需要从这个表中查找出所有名字是‘ZhangSan’的雇员信息，你会快速的写出SQL语句：
前几天，在朋友圈发了一个关于联合索引的笔试题，我简单说了我的想法，然后看看朋友圈其他大佬的想法。
很多时候，我们的慢查询，都是因为没有加索引。如果没有加索引的话，会导致全表扫描的。因此，应考虑在 where 的条件列，建立索引，尽量避免全表扫描。
本系列文章将整理到我在GitHub上的《Java面试指南》仓库，更多精彩内容请到我的仓库里查看
很明显，不同的类型存储的长度有很大区别的，对查询的效率有影响，字段长度对索引的影响是很大的。
日常开发中，我们经常会遇到数据库慢查询。那么导致数据慢查询都有哪些常见的原因呢？今天田螺哥就跟大家聊聊导致MySQL慢查询的12个常见原因，以及对应的解决方法。
某一天，楼主打完上班卡，坐在工位逛园子的时候，右下角的 QQ 闪了起来，而且还是个美女头像！我又惊又喜，脑中闪过我所认识的可能联系我的女性，得出个结论：她们这会不可能联系我呀，图像也没映象，到底是谁了？打开聊天窗口聊了起来
数据库的管理是一个非常专业的事情，对数据库的调优、监控一般是由数据库工程师完成，但是开发人员也经常与数据库打交道，即使是简单的增删改查也是有很多窍门，这里，一起来聊聊数据库中很容易忽略的问题。 字段长度省着点用 先说说我们常用的类型的存储长度： 列类型存储长度tinyint1字节smallint2字节int4字节bigint8字节float4字节decimal(m,d)0-4字节datetime8字节timestamp4字节char(m)m个字节varchar(m)可变长度text可变长度 很明显，不同的类
在数据库中，对无索引的表进行查询或者有索引但是MySQL查询优化器不选择使用索引而进行的查询被称为全表扫描。如何判断当前某个
实战部分挑选一些比较常见的情况，事先强调个人使用的是mysql 8.0.26，所以不同版本如果出现不同测试结果也不要惊讶，新版本会对于过去一些不会优化的查询进行优化。
实战部分回挑选一些比较常见的情况，事先强调个人使用的是「mysql 8.0.26」，所以不同版本如果出现不同测试结果也不要惊讶，新版本会对于过去一些不会优化的查询进行优化。
一连串的自问自答，我想起来了，是由于之前的某张统计表设计的不太合理，导致表内数据时间段内冗余较多，而统计展示又要很精细，所以逼出了我的这句祖传sql，嗯，都是表设计的锅，哈哈哈，甩锅成功！
在MySQL中，我们可以通过EXPLAIN命令获取MySQL如何执行SELECT语句的信息，包括在SELECT语句执行过程中表如何连接和连接的顺序。
在尝试编写快速的查询之前,需要清楚一点,真正重要是响应时间。如果把查询看作是一个任务，那么他由一系列子任务组成，每个子任务都会消耗一定的时间。如果要优化查询，实际上要优化其子任务，要么消除其中一些子任务，要么减少子任务的执行的次数，要么让子任务运行得更快。
1、客户端端与Mysql服务端的连接层建立连接，根据请求类型去选择相应的服务层的请求接口。
原因是会造成全表扫描，有位读者说这种说法是有问题的，实际上针对无 where_clause 的 COUNT(*)，MySQL 是有优化的，优化器会选择成本最小的辅助索引查询计数，其实反而性能最高，这位读者的说法对不对呢
一般情况下，我们会在一个索引上较多的使用等值查询或者范围查询，此时索引大多可以帮助我们极快的查询出我们需要的数据。
提到信息搜集其实大家都不陌生，但是或许有人会有疑问信息搜集中的数据分析是什么？在讲数据分析之前我们思考一个比较常见的问题，有哪些方式来确定两个域名是同一个公司的资产，读者在公布答案之前可以先思考下这个问题，下面说下笔者的思考：
这张表中的activated_time和store_id均有索引，但是先线上explain时却是走的全表扫描。
innodb_io_capacity：脏页的刷新的数量，可以动态调整，默认是200，该参数的设置取决于硬盘的IOPS的大小，IOPS就是每秒的读写次数。
2021-01-19：mysql中，一张表里有3亿数据，未分表，其中一个字段是企业类型，企业类型是一般企业和个体户，个体户的数据量差不多占50%，根据条件把个体户的行都删掉。请问如何操作？
最近面试被问到这样一个问题。这里总结一下。关于更多的MySQL真题，你可以直接访问该链接进行查看。
这两天看到了两种可能会导致全表扫描的sql，这里给大家看一下，希望可以避免踩坑：
几乎所有的小伙伴都可以随口说几句关于创建索引的优缺点，也知道什么时候创建索引能够提高我们的查询性能，什么时候索引会更新，但是你有没有注意到，即使你设置了索引，有些时候索引他是不会生效的！这不仅考察了大家对索引的了解程度，还要让大家在使用的时候能够正确的使用。以下介绍了一些可能会造成索引失效的特殊情况，希望大家在平时开发和面试的时候能够注意到！
我的主机内存只有100G，现在要全表扫描一个200G大表，会不会把DB主机的内存用光？
转载自 http://blog.csdn.net/tiantang_1986/article/details/76890178
执行show create table order_info 发现这个表其实是有加索引的
【Server Configuration Type】该选项用于设置服务器的类型。单击该选项右侧的向下按钮， 即可看到包括3个选项。
在MySQL中，执行计划是优化器根据查询语句生成的一种重要的数据结构，它描述了如何通过组合底层操作实现查询的逻辑。当我们编写一条SQL语句时，MySQL会自动对其进行优化，并生成最优的执行计划以实现更快的查询速度。
点击上方“芋道源码”，选择“设为星标” 管她前浪，还是后浪？ 能浪的浪，才是好浪！ 每天 10:33 更新文章，每天掉亿点点头发... 源码精品专栏 原创 | Java 2021 超神之路，很肝~ 中文详细注释的开源项目 RPC 框架 Dubbo 源码解析 网络应用框架 Netty 源码解析 消息中间件 RocketMQ 源码解析 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析 作业调度中间件 Elastic-Job 源码解析 分布式事务中间件 TCC-Transaction
通过explain的执行结果我们可以看出，上面的SQL语句并没有走我们的索引a，而是直接使用了全表扫描。
为什么你写的sql查询慢？为什么你建的索引常失效？ 通过本篇内容，你将学会MySQL性能下降的原因，索引的简介，索引创建的原则，explain命令的使用，以及explain输出字段的意义。助你了解索引，分析索引，使用索引，从而写出更高性能的sql语句。
用or分割开的条件， 如果or前的条件中的列有索引，而后面的列中没有索引，那么涉及的索引都不会被用到。
SS可以兼容的，XS、SX、XX之间是互斥的，即读锁之间可以共享，读写和写写之间是不兼容的
过年回来的第二周了，终于有时间继续总结知识了。这次来看一下SQL调优的知识，这类问题基本上面试的时候都会被问到，无论你的岗位是后端，运维，测试等等。 像本文标题中的两个问题，就是我在实际面试过程中遇到的，所以这次就主要围绕着这两个问题来总结一下。
前段时间，博主线上项目的几个后端接口执行耗时达到了三、四秒钟以上，查看接口代码，发现 sql 语句执行过慢，于是开始分析 sql 执行 这里把比较经典的优化案例分享给大家。
我经常会被问到这样一个问题：我的主机内存只有 100G，现在要对一个 200G 的大表做全表扫描，会不会把数据库主机的内存用光了？
一条SQL被一个懵懂的少年，一阵蹂躏，扔向了MySQL服务器的尽头，少年苦苦等待，却迟迟等不来那满载而归的硕果。于是少年气愤，费尽苦心想从度娘那边寻求帮助，面对执行计划EXPLAIN，却等来的是无尽的折磨与抓狂。
内容概要 利用主索引提升SQL的查询效率是我们经常使用的一个技巧，但是有些时候MySQL给出的执行计划却完全出乎我们的意料，我们预想MySQL会通过索引扫描完成查询，但是MySQL给出的执行计划却是通过全表扫描完成查询的，其中的某些场景我们可以利用覆盖索引进行优化。 前些天，有个同事跟我说：“我写了个SQL，SQL很简单，但是查询速度很慢，并且针对查询条件创建了索引，然而索引却不起作用，你帮我看看有没有办法优化？”。 我对他提供的case进行了优化，并将优化过程整理了下来。 优化前的表结构、数据量、SQL、
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
