保暖透气大裤衩LeoLee的博客

表锁偏向MyISAM，开销小，加锁快，无死锁，锁粒度大，发生锁冲突的概率较高，并发度较低。表锁分析测试表：CREATE TABLE IF NOT EXISTS table_lock ( id INT(10) PRIMARY KEY NOT NULL AUTO_INCREMENT COMMENT '自增主键', `name` VARCHAR(24) NOT NULL DEFAULT '' COMMENT '姓名') ENGINE=MyISAM;INSERT INTO table_l

索引相关基础基础知识：Mysql——SQL性能优化基础知识小表驱动大表SELECT * FROM staff s WHERE s.department_id IN (SELCET id FROM department WHERE ...);以Mysql优化器对这条查询语句的理解，应该是先检索子句，在检索主句，即先查询符合条件的部门，再查询员工表数据与子句的结果集进行比较，大致过程如下：for ([department表数据]检索复合条件的部门集A) { for ([staff表数

索引相关基础基础知识：Mysql——SQL性能优化基础知识测试表创建：CREATE TABLE IF NOT EXISTS staff ( id INT(10) PRIMARY KEY NOT NULL AUTO_INCREMENT COMMENT '自增主键', name VARCHAR(24) NOT NULL DEFAULT '' COMMENT '姓名', age INT(4) NOT NULL DEFAULT 0 COMMENT '年龄', position VARCHAR(32

数据库查询慢基本与以下几点相关查询语句写的烂 索引失效 关联查询太多 服务器调优差，Mysql参数配置不理想作为后端开发，其实最关注的是前三点，第三点有些特殊，可能工作中很多情况是不得已才会写出一个很多表关联的SQL，比如表结构设计已经定性，由于业务的发展，导致之前看似合理的表结构在当下业务中显得不再合理，亦或者是某些“令人头疼”的不合理业务要求造成的。优化基础SQL的执行顺序SQL的执行顺序其实很多稍微研究过的朋友已经知道了，我们“手写”的SQL和数据库理解的SQL顺序其实是不一样

前言最近踩了一个大坑，虽然快速解决了，但是当时也没有想明白为什么。起因是在改造一条sql语句时候，需要加group by，我当时就没有多想，直接就加上了，确认了sql可以正常查询之后，我就开始运行项目测试了。用的是baomidou的mybitis插件，这个查询最终是会通过mybatis的处理加上limit的，然后让我震惊的现象出现了，这条我在数据库操作工具测试过的sql，在加上了limit之后...

MySQL——通过EXPLAIN分析SQL的执行计划在MySQL中，我们可以通过EXPLAIN命令获取MySQL如何执行SELECT语句的信息，包括在SELECT语句执行过程中表如何连接和连接的顺序。下面分别对EXPLAIN命令结果的每一列进行说明： select_type:表示SELECT的类型，常见的取值有： 类型 说明 SIMPLE 简单表，不使用...