公司订单系统每日订单量庞大,有很多表数据超千万.公司SQL优化这块做的很不好,可以说是没有做,所以导致查询很慢. 正题 节选某个功能中的一句SQL EXPLAIN 查看执行计划 EXPLAIN + SQL 查看SQL执行计划 一个索引没用到,受影响行接近2000万,难怪会慢. 原来的SQL打印出来估计有好几张A4纸,我发个整理后的简版. SELECT COUNT(t.w_order_id) lineCount, , )) AS lineTotalFee, , )) AS lineFactFee

订单的表结构采用了垂直分表的策略,将订单相关的不同模块的字段维护在不同表中 在订单处理这个页面,需要查询各种维度, 因此为了方便查询创建了v_sale_order视图(老版本) drop view v_sale_order; CREATE VIEW `v_sale_order` AS SELECT `so`.`sale_order_id` AS `v_sale_order_id`, `so`.`sale_order_id` AS `sale_order_id`, `so`.`sale_order

订单的表结构采用了垂直分表的策略,将订单相关的不同模块的字段维护在不同表中 在订单处理这个页面,需要查询各种维度, 因此为了方便查询创建了v_sale_order视图(老版本) drop view v_sale_order; CREATE VIEW `v_sale_order` AS SELECT `so`.`sale_order_id` AS `v_sale_order_id`, `so`.`sale_order_id` AS `sale_order_id`, `so`.`sale_order

优化嵌套查询 嵌套查询(子查询)可以使用SELECT语句来创建一个单列的查询结果,然后把这个结果作为过滤条件用在另一个查询中.嵌套查询写起来简单,也容易理解.但是,有时候可以被更有效率的连接(JOIN)替代. 现在假如要找出从来没有在网站中消费的客户,也就是查询在客户customer表中但是不在支付payment表中的客户信息. 嵌套查询: explain select * from customer where customer_id not in (select customer_id fr

订单分页查询: 老的代码是顺序执行查询数据和计算总记录数,但是如果条件复杂的话(比如关联子表)查询的时间要超过20s种 public static PagedList<Map<String, Object>> query(ITemplateService service, Identity tenantId, Identity userId, String entityName, Map<String, Object> params, String columns, T

使用MySql查询缓存(query_cache_size) 在MySql中查询缓存的原理: 其实是MySql创建了一个临时的空间叫Qcache(这个空间生成在MySql的编译器内存中),这个空间的大小是用字节大小来计算的,所以缓存多少数据可以根据需求进行调节.如果是第一次查询,则从硬盘找查找并返回结果,如果有记录返回Qcache会记录查找到的结果,当用户发出第二次查询,MySql就会询问Qcache是否已经存在了这个查询.如果存在则从Qcache中返回查询结果,如果不存在则又一次从硬盘中查找结果

COUNT()聚合函数,以及如何优化使用了该函数的查询,很可能是最容易被人们误解的知识点之一 COUNT()的作用 COUNT()是一个特殊的函数,有两种非常不同的作用: 统计某个列值的数量 统计行数 统计列值 在统计列值时,要求列值是非空的,即不统计NULL.如果在COUNT()的括号中指定了列或者列的表达式,则统计的就是这个表达式有值的结果数. 统计结果集的行数 当MySQL确认括号内的表达式的值不可能为空时,实际上就是在统计行数,最简单的就是当我们使用COUNT(*)的时候,这种情况下通配

1.COUNT(*)和COUNT(COL) COUNT(*)通常是对主键进行索引扫描,而COUNT(COL)就不一定了,另外前者是统计表中的所有符合的纪录总数,而后者是计算表中所有符合的COL的纪录数.还有有区别的.优化总结,对于MyISAM表来说: 1.任何情况下SELECT COUNT(*) FROM tablename是最优选择: 2.尽量减少SELECT COUNT(*) FROMtablename WHERE COL = 'value' 这种查询: 3.杜绝SELECT COUNT(C

订单分页查询: 老的代码是顺序执行查询数据和计算总记录数,但是如果条件复杂的话(比如关联子表)查询的时间要超过20s种 public static PagedList<Map<String, Object>> query(ITemplateService service, Identity tenantId, Identity userId, String entityName, Map<String, Object> params, String columns, T

用子查询语句来影响子查询中产生结果rows的数量和顺序. For example: SELECT * FROM t1 WHERE t1.column1 IN (SELECT column1 FROM t2 ORDER BY column1); SELECT * FROM t1 WHERE t1.column1 IN (SELECT DISTINCT column1 FROM t2); SELECT * FROM t1 WHERE EXISTS ();//limit关键字不在含有in关键字的子查询

Mysql 系列文章主页 =============== 默认没有开启慢查询日志功能.如果不是调优需要的话,一般不建议开启. 查看是否开启慢查询日志: SHOW VARIABLES LIKE '%slow_query_log%' 开启: ; 如果开启了此功能,那,什么样的Sql才会被记录到慢查询日志里面呢? 这是由参数 long_query_time 控制的,默认值 10秒,查看命令如下: SHOW VARIABLES LIKE '%long_query_time%'; 注意:是要严格大于 lo

对于缓存,一般人想到的是 redis.memcache 这些内存型的缓存. 但是实际上 mysql 也提供了缓存,mysql 里面的缓存是查询缓存,可以把我们查询过的语句缓存下来,下一次查询的时候有可能就直接从缓存返回(缓存命中). 当然使用 mysql 缓存也不是没有坏处,mysql 多了个管理缓存的任务,需要写入缓存,然后如果判断里面的缓存已经过期,又要从里面删除缓存. 查看查询缓存情况: mysql> show variables like '%query_cache%';  (query

1.显示慢查询的一些参数的命令:show variables like '%slow%';结果如图

1. like %keyword    索引失效,使用全表扫描.但可以通过翻转函数+like前模糊查询+建立翻转函数索引=走翻转函数索引,不走全表扫描. 2. like keyword%    索引有效. 3. like %keyword% 索引失效,也无法使用反向索引. ==================================================================== 1. 使用下面的函数来进行模糊查询,如果出现的位置〉0,表示包含该字符串. 查询效率比l

1.  MySQL优化-查看执行记录 MySQL 提供了一个 EXPLAIN 命令, 它可以对 SELECT 语句进行分析, 并输出 SELECT 执行的详细信息, 以供开发人员针对性优化. 使用explain这个命令来查看一个这些SQL语句的执行计划,查看该SQL语句有没有使用上了索引,有没有做全表扫描,这都可以通过explain命令来查看. EXPLAIN 命令用法十分简单, 在 SELECT 语句前加上 explain 就可以了, 例如: 1.1   SQL语句优化-explain分析问题

一.Mysql的存储原理 索引相关 本质 ​ 索引是帮助MySQL高效获取数据的排好序的数据结构 ​ 建索引,提高数据检索的效率,降低数据库的IO成本: 通过索引列对数据进行排序,降低数据排序的成本,降低了 CPU的消耗. 索引分类 主键索引:主键自带索引效果,性能很好 普通索引:为普通列创建的索引 -- 格式 create index 索引名称 on 表名(列名); -- 示例 create index idx_name on user(name); 唯一索引 : 索引列的值必须唯一,但允许有

一.优化概述 二.查询与索引优化分析 1性能瓶颈定位 Show命令 慢查询日志 explain分析查询 profiling分析查询 2索引及查询优化 三.配置优化 1)      max_connections 2)      back_log 3)      interactive_timeout 4)      key_buffer_size 5)      query_cache_size 6)      record_buffer_size 7)      read_rnd_buffer

mysql in 子查询 效率慢 优化(转) 现在的CMS系统.博客系统.BBS等都喜欢使用标签tag作交叉链接,因此我也尝鲜用了下.但用了后发现我想查询某个tag的文章列表时速度很慢,达到5秒之久!百思不解(后来终于解决),我的表结构是下面这样的,文章只有690篇. 文章表article(id,title,content)标签表tag(tid,tag_name)标签文章中间表article_tag(id,tag_id,article_id)其中有个标签的tid是135,我帮查询标签tid是13

查询性能优化 1. 为什么查询速度会慢? 1). 如果把查询看作是一个任务,那么它由一系列子任务组成,每个子任务都会消耗一定的时间.如果要优化查询,实际上要优化其子任务,要么消除其中一些子任务,要么减少子任务的执行次数,要么让子任务运行的更快. 2). 通常来说,查询的生命周期大致可以按照顺序来看:从客户端,到服务器端,然后在服务器上进行解析,生成执行计划,执行,并返回结果给客户端.其中"执行"可以认为是整个生命周期中最重要的阶段,这其中包括 大量为了检索数据到存储引擎的调用以及调用后

对于高性能数据库操作,只靠设计最优的库表结构.建立最好的索引是不够的,还需要合理的设计查询.如果查询写得很糟糕,即使库表结构再合理.索引再合适,也无法实现高性能.查询优化.索引优化.库表结构优化需要齐头并进,一个不落. 6.1 为什么查询速度会慢 通常来说,查询的生命周期大致可以按照顺序来看:从客户端>>服务器>>在服务器上进行解析>>生成执行计划>>执行>>返回结果给客户端.其中执行可以认为是整个生命周期中最重要的阶段,这其中包括了大量为了检索

本篇深入了解查询优化和服务器的内部机制,了解MySql如何执行特定查询,从中也可以知道如何更改查询执行计划,当我们深入理解MySql如何真正地执行查询,明白高效和低效的真正含义,在实际应用中就能扬长避短. 声明:本人使用的数据库版本为MySql 5.1 一.基本原则:优化数据访问 查询性能低下的最基本原因就是访问了太多数据,一些查询要不可避免地筛选大量的数据,大部分性能欠佳的查询都可以用减少数据访问的方式进行优化. 1.首先分析应用程序是否正在获取超过需要的数据,这通常表现在获取了过多的行或列.