分析案例:1.走rule很快,但是收集了执行计划后却很慢SQL> create table test(id int);
表已创建。
SQL> insert into test select 1 from dba_objects;
已创建49883行。
SQL> commit;
提交完成。
SQL> insert into test select 2 from u
转载
2024-03-14 09:38:23
71阅读
因为优化器还不够强大，还有很多限制，或者因为一些逻辑原因，分析认为SQL要走索引比较好，但是事实却无法正确利用索引。这时候，除了给ORACLE需要的统计信息之外，写的SQL必须要能够给优化器足够多的额外有效信息，让优化器能够选择更好的执行计划。要让给优化器正确使用上需要的索引，要考虑两点：1).如何避免优化器的限制 2).根据业务数据特点改写SQL语句 &nb
转载
2023-07-22 20:08:29
142阅读
背景有客户提出一个问题。 一个类似这样的SQL语句，select count(id) from 为什么执行计划用全表扫，不用索引。id列上有主键。分析test=# explain (analyze, buffers ) select count(id) from t1;
QUERY PLAN
--
转载
2024-07-05 10:42:03
48阅读
SQL优化器简介 基于规则的优化器 。总是使用索引 。总是从驱动表开始（from子句最右边的表） 。只有在不可避免的情况下，才使用全表扫描 。任何索引都可以 基于成本的优化器 。需要表、索引的统计资料 Analyze table customer compute statistics; Analyze table customer estimate statistics sample 5000 r
转载
2024-04-25 22:33:28
44阅读
因为优化器还不够强大，还有很多限制，或者因为一些逻辑原因，分析认为SQL要走索引比较好，但是事实却无法正确利用索引。这时候，除了给ORACLE需要的统计信息之外，写的SQL必须要能够给优化器足够多的额外有效信息，让优化器能够选择更好的执行计划。 要让给优化器正确使用上需要的索引，要考虑两点： 1).如何避免优化器的限制 2).根据业务数据特点改写SQL语句
转载
2024-05-12 15:29:37
60阅读
在MySQL中，并不是你建立了索引，并且你在SQL中使用到了该列，MySQL就肯定会使用到那些索引的，有一些情况很可能在你不知不觉中，你就“成功的避开了”MySQL的所有索引。 现假设有t_stu表，age,sname上建立了索引 索引列参与计算 如果where条件中age列中使用了计算，则不会使用该索引 SELECT `sname` FROM `t_stu` WHERE `age`=20;--
转载
2024-03-19 22:02:22
68阅读
說明:logistics_detail表中每個deliver_id可能對應多個loginticsType,但是我們只要獲取最大的那一個.SELECT dm.delivery_code,dm.deliver_id,om.order_id,DATE(FROM_UNIXTIME(om.order_createdate)) as order_date,om.order_status,om.order_pa
转载
2024-07-29 11:27:09
45阅读
一、分析索引 1.概念： 1、高基数：简单理解就是表中列的不同值多。 2、低基数：建单理解就是表中的列的不同值少 3、已删除的叶节点数量：指得是数据行的delete操作从逻辑上删除的索引节点 的数量，要记住oracle在删除数据行后，将 “ 死 “ 节点保留在索引中，这样做可以加快sql删除操作的速度，因此oracle删除数据行后可以
字段说明：
type列，连接类型。一个好的SQL语句至少要达到range级别。杜绝出现all级别。
possible_keys: 表示查询时可能使用的索引。
key列，使用到的索引名。如果没有选择索引，值是NULL。可以采取强制索引方式。
key_len列，索引长度。
rows列，扫描行数。估算的找到所需的记录所需要读取的行数。
extra列，详细说明。注意，常见的不太友好的值，如下：Using
转载
2023-07-05 10:51:06
131阅读
优化的要领：尽量避免 表扫描 和 索引扫描，让查询尽量走索引或者全文索引 用索引做优化，实际上试用空间换时间 1.举例：1. select id from t where num=10or Name ='admin' 2. select id from t where num = 10unionallselect id from t where Name ='admi
转载
2024-05-07 13:54:29
133阅读
在很多情况下，如果我们要做一些筛选，很多时候很自然的想到用in语句。比如 select * from user where id in (id1, id2, id3, ...., idN);数据量不多的时候，这么做确实没有什么问题，无非是全表扫描。关于oracle中in语法的劣势，网上有很多文档可以参考，还有很多关于用exist替代in的方案。在这里就不讨论了。先来说说我碰到了案例吧。表中有百万条
首先写几个费解的例子（mysql是否走索引 都是由很多因素导致 下面写了trace工具可以进行分析）首先这是一个聚合索引的顺序 name,age,postiton
EXPLAIN SELECT * FROM emp WHERE name > 'am' AND age = 22 postition = '12'
上面这个sql第一个字段使用的是范围查找这样就不会走索引了 原因就是数据庞大 还
通过一些日常的开发经验，归纳了一些不走索引的常规情况，欢迎大家补充或指正。在字符集不一致的时候，不走索引。如果两个关联表的字符集不一致，会导致索引失效，因此，在生产环境执行DDL建表语句时，要注意不要指定某表或某字段（尤其是关联字段）的字符集，让整个数据库的字符集一致，这样可以避免因字符集导致索引失效的慢sql的问题。在字段类型不一致的时候，不走索引。如果有两个关联键字段类型不一致的时候，会导致索
转载
2023-12-31 21:29:39
167阅读
有一个老的问题经常会问道数据库转件就是为什么或者为什么表的索引没有被使用？下面的文章将会简单的回答这个常见的问题，并按着统计学意义排序。一、对于外行人来说，你怎么知道索引没有被使用呢？可以使用 EXPLAIN ; EXPLAIN ANALYZE 或者 pgadmin 的图形执行计划来查看。 ">http://www.postgresonline.com/journal/archives/27
转载
2024-04-22 12:02:12
281阅读
今天早上查看网站，发现非常慢！进linux 用top查看，发现MySQL cpu到了100%。开始怀疑是mysql性能的问题，不会10万条数据就卡成这样吧？虽然我的linux是在服务器上放了个虚拟机，但也不至于10万条记录挂啊？ 网上找了一大把文章，my.cnf也设置了，我虚拟机内存是2G,将key_buf设置成512M 还是卡。非常郁
转载
2024-03-21 21:33:11
45阅读
声明：本文思路来源于laoxiong老师的博文，就此感谢！在Oralce的搜索中，如果where条件句后使用了is null搜索条件，那么即使该列上使用了索引，Oracle也不会进行索引搜索。那么，这条规则一定正确吗？构建实验环境准备数据环境，构建数据表。SQL> create table t as select object_id,object_name,owner from dba_ob
转载
2024-08-31 19:39:01
27阅读
我的问题：你们看我这个，1号的就走索引，4号的不走索引要全表，我希望4号走索引，加了强制走索引的语句也不管用，怎办？（我的语句：）update t_mt partition(P_MT5_1) mt set (mt.stat,mt.rpttime)=(select stat,rpttime from t_statbuf buf
where sj>=to_date('2013-05-04
转载
2024-04-12 15:10:43
74阅读
一、操作符优化： 1、IN 操作符
用IN写出来的SQL的优点是比较容易写及清晰易懂，这比较适合现代软件开发的风格。
但是用IN的SQL性能总是比较低的，从ORACLE执行的步骤来分析用IN的SQL与不用IN的SQL有以下区别：
本系列文章目录
展开/收起
Mysql索引篇（一） 索引的数据结构B+树Mysql索引篇（二） Myisam和Innodb的索引Mysql索引篇（三） 善于explain分析sql语句Mysql索引篇（四） 覆盖索引(Using index)、文件排序(Using filesort)和临时表(Using temporary)Mysql索引篇（五） Sql优
表t_busi_main_presend2建了索引T_BUSI_MAIN_PRESEND2_SHSTATUS在SHSTATUS字段，SHSTATUS char(1) default '0'，只有2个值 '0' ,'1'。初始值为‘0’，处理之后为‘1’，表中几十万数据，大部分为‘1’，现在有8条为‘0’。现在，建索引(类型为normal,不能bitmap，会锁)后，下面语句竟然是全表！select
转载
2024-07-08 21:20:39
77阅读
