提高count查询速度

最新推荐文章于 2024-01-31 14:46:09 发布
最新推荐文章于 2024-01-31 14:46:09 发布
阅读量301 收藏
点赞数
显然昨天做的分区并未提升count(1)的查询速度，怎样都避免不了全表扫描，后来开始在网上搜索，发现的确有很多方法，所以准备挨个尝试
首先正常查询一次
10:19:30 SQL> select count(1) from trans_tmp;

  COUNT(1)
----------
   8997943

已用时间:  00: 03: 23.76

执行计划
----------------------------------------------------------
Plan hash value: 55114451

-------------------------------------------------------------------------------------
| Id  | Operation             | Name                | Rows  | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |                     |     1 |  6382   (5)| 00:01:17 |
|   1 |  SORT AGGREGATE       |                     |     1 |            |          |
|   2 |   INDEX FAST FULL SCAN| TRANS_TMP_ID |    11M|  6382   (5)| 00:01:17 |
-------------------------------------------------------------------------------------


统计信息
----------------------------------------------------------
        231  recursive calls
          0  db block gets
      28019  consistent gets
      22734  physical reads
          0  redo size
        411  bytes sent via SQL*Net to client
        400  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          5  sorts (memory)
          0  sorts (disk)
          1  rows processed

3分多钟，6382 cost
1.尝试bitmap索引，还是以id列做索引
首先删掉之前的btree索引
drop index trans_tmp_id;
唉，这就执行了好久，然后建立bitmap索引
create bitmap index bitmap_idx_id on trans_tmp(id) online;
因为应用还在跑着，所以采用online的方式，漫长等待后，进行查询

10:43:52 SQL> select count(1) from trans_tmp;

  COUNT(1)
----------
   8997943

已用时间:  00: 03: 57.18

执行计划
----------------------------------------------------------
Plan hash value: 3875526975

---------------------------------------------------------------------------------------
| Id  | Operation                     | Name          | Rows  | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |               |     1 | 29563   (1)| 00:05:55 |
|   1 |  SORT AGGREGATE               |               |     1 |            |          |
|   2 |   BITMAP CONVERSION COUNT     |               |    11M| 29563   (1)| 00:05:55 |
|   3 |    BITMAP INDEX FAST FULL SCAN| BITMAP_IDX_ID |       |            |          |
---------------------------------------------------------------------------------------


统计信息
----------------------------------------------------------
          1  recursive calls
          0  db block gets
      40454  consistent gets
      32655  physical reads
          0  redo size
        411  bytes sent via SQL*Net to client
        400  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

近4分钟，而且cost 29563，怎么更高了呢？继续在这上尝试

2.更改bitmap索引并行
10:52:37 SQL> alter index bitmap_idx_id parallel 4;

索引已更改。

10:54:40 SQL> select count(1) from trans_tmp;

已用时间:  00: 03: 40.23

执行计划
----------------------------------------------------------
Plan hash value: 408296253

------------------------------------------------------------------------------------------------------------------------

| Id  | Operation                         | Name          | Rows  | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |

------------------------------------------------------------------------------------------------------------------------

|   0 | SELECT STATEMENT                  |               |     1 | 29563   (1)| 00:05:55 |        |   |               |

|   1 |  SORT AGGREGATE                   |               |     1 |            |          |        |   |               |

|   2 |   PX COORDINATOR                  |               |       |            |          |        |   |               |

|   3 |    PX SEND QC (RANDOM)            | :TQ10000      |     1 |            |          |  Q1,00 | P->S | QC (RAND)  |

|   4 |     SORT AGGREGATE                |               |     1 |            |          |  Q1,00 | PCWP |            |

|   5 |      PX BLOCK ITERATOR            |               |    11M| 29563   (1)| 00:05:55 |  Q1,00 | PCWC |            |

|   6 |       BITMAP CONVERSION COUNT     |               |    11M| 29563   (1)| 00:05:55 |  Q1,00 | PCWP |            |

|   7 |        BITMAP INDEX FAST FULL SCAN| BITMAP_IDX_ID |       |            |          |  Q1,00 | PCWP |            |

------------------------------------------------------------------------------------------------------------------------



统计信息
----------------------------------------------------------
        939  recursive calls
          3  db block gets
      33540  consistent gets
      32656  physical reads
        628  redo size
        411  bytes sent via SQL*Net to client
        400  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
         14  sorts (memory)
          0  sorts (disk)
          1  rows processed

时间只减少了10几秒，cost 29563 一点没变；既然并行了索引，那么也并行表吧
10:58:32 SQL> alter table trans_tmp parallel 4;

表已更改。

11:01:08 SQL> select count(1) from trans_tmp;
已用时间:  00: 00: 01.03

执行计划
----------------------------------------------------------
Plan hash value: 408296253

------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                         | Name          | Rows  | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |
------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                  |               |     1 |  8212   (1)| 00:01:39 |        |   |               |
|   1 |  SORT AGGREGATE                   |               |     1 |            |          |        |   |               |
|   2 |   PX COORDINATOR                  |               |       |            |          |        |   |               |
|   3 |    PX SEND QC (RANDOM)            | :TQ10000      |     1 |            |          |  Q1,00 | P->S | QC (RAND)  |
|   4 |     SORT AGGREGATE                |               |     1 |            |          |  Q1,00 | PCWP |            |
|   5 |      PX BLOCK ITERATOR            |               |    11M|  8212   (1)| 00:01:39 |  Q1,00 | PCWC |            |
|   6 |       BITMAP CONVERSION COUNT     |               |    11M|  8212   (1)| 00:01:39 |  Q1,00 | PCWP |            |
|   7 |        BITMAP INDEX FAST FULL SCAN| BITMAP_IDX_ID |       |            |          |  Q1,00 | PCWP |            |
------------------------------------------------------------------------------------------------------------------------

去掉了查询部分，只看执行计划，这回cost 8212，下来不少
3.禁用索引，并行扫描全表

11:03:15 SQL> select /*+full(trans_tmp)parallel(trans_tmp 2)*/ count(1) from trans_tmp;
已用时间:  00: 00: 00.17

执行计划
----------------------------------------------------------
Plan hash value: 1765477136

----------------------------------------------------------------------------------------------------------------
| Id  | Operation              | Name             | Rows  | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |
----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT       |                  |     1 | 93757   (1)| 00:18:46 |        |      |         |
|   1 |  SORT AGGREGATE        |                  |     1 |            |          |        |      |         |
|   2 |   PX COORDINATOR       |                  |       |            |          |        |      |         |
|   3 |    PX SEND QC (RANDOM) | :TQ10000         |     1 |            |          |  Q1,00 | P->S | QC (RAND)  |
|   4 |     SORT AGGREGATE     |                  |     1 |            |          |  Q1,00 | PCWP |         |
|   5 |      PX BLOCK ITERATOR |                  |    11M| 93757   (1)| 00:18:46 |  Q1,00 | PCWC |         |
|   6 |       TABLE ACCESS FULL| TRANS_TMP |    11M| 93757   (1)| 00:18:46 |  Q1,00 | PCWP |         |
----------------------------------------------------------------------------------------------------------------
cost 93757 看来很高，不过之前已经把并行度改成了4，那么直接查询试试看

11:06:45 SQL> select  /*+full(trans_tmp)*/ count(1) from trans_tmp;
已用时间:  00: 00: 00.96

执行计划
----------------------------------------------------------
Plan hash value: 1765477136

----------------------------------------------------------------------------------------------------------------
| Id  | Operation              | Name             | Rows  | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |
----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT       |                  |     1 | 46879   (1)| 00:09:23 |        |      |         |
|   1 |  SORT AGGREGATE        |                  |     1 |            |          |        |      |         |
|   2 |   PX COORDINATOR       |                  |       |            |          |        |      |         |
|   3 |    PX SEND QC (RANDOM) | :TQ10000         |     1 |            |          |  Q1,00 | P->S | QC (RAND)  |
|   4 |     SORT AGGREGATE     |                  |     1 |            |          |  Q1,00 | PCWP |         |
|   5 |      PX BLOCK ITERATOR |                  |    11M| 46879   (1)| 00:09:23 |  Q1,00 | PCWC |         |
|   6 |       TABLE ACCESS FULL| TRANS_TMP |    11M| 46879   (1)| 00:09:23 |  Q1,00 | PCWP |         |
----------------------------------------------------------------------------------------------------------------
cost 46897 降了一半左右,既然bitmap索引效果不大，删掉，然后重建btree索引继续尝试并行
4.btree索引并行
11:03:34 SQL> drop index bitmap_idx_id;

索引已删除。
11:07:11 SQL> create index trans_tmp_id on trans_tmp(id) online;

索引已创建。

11:13:51 SQL> alter index trans_tmp_id parallel 4;

索引已更改。

已用时间:  00: 00: 00.32

11:27:44 SQL> select count(1) from trans_tmp;
已用时间:  00: 00: 00.42

执行计划
----------------------------------------------------------
Plan hash value: 1765477136

----------------------------------------------------------------------------------------------------------------
| Id  | Operation              | Name             | Rows  | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |
----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT       |                  |     1 | 46879   (1)| 00:09:23 |        |      |         |
|   1 |  SORT AGGREGATE        |                  |     1 |            |          |        |      |         |
|   2 |   PX COORDINATOR       |                  |       |            |          |        |      |         |
|   3 |    PX SEND QC (RANDOM) | :TQ10000         |     1 |            |          |  Q1,00 | P->S | QC (RAND)  |
|   4 |     SORT AGGREGATE     |                  |     1 |            |          |  Q1,00 | PCWP |         |
|   5 |      PX BLOCK ITERATOR |                  |    11M| 46879   (1)| 00:09:23 |  Q1,00 | PCWC |         |
|   6 |       TABLE ACCESS FULL| TRANS_TMP |    11M| 46879   (1)| 00:09:23 |  Q1,00 | PCWP |         |
----------------------------------------------------------------------------------------------------------------
全表扫描了？gather stat了一下还是全表，那么就强制走索引吧

11:32:03 SQL> select /*+rule*/ count(1) from trans_tmp;
已用时间:  00: 00: 00.18

执行计划
----------------------------------------------------------
Plan hash value: 1765477136

----------------------------------------------------------------------------------------------------------------
| Id  | Operation              | Name             | Rows  | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |
----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT       |                  |     1 | 46879   (1)| 00:09:23 |        |      |         |
|   1 |  SORT AGGREGATE        |                  |     1 |            |          |        |      |         |
|   2 |   PX COORDINATOR       |                  |       |            |          |        |      |         |
|   3 |    PX SEND QC (RANDOM) | :TQ10000         |     1 |            |          |  Q1,00 | P->S | QC (RAND)  |
|   4 |     SORT AGGREGATE     |                  |     1 |            |          |  Q1,00 | PCWP |         |
|   5 |      PX BLOCK ITERATOR |                  |    11M| 46879   (1)| 00:09:23 |  Q1,00 | PCWC |         |
|   6 |       TABLE ACCESS FULL| TRANS_TMP |    11M| 46879   (1)| 00:09:23 |  Q1,00 | PCWP |         |
----------------------------------------------------------------------------------------------------------------
呃，竟然一样，好吧，我准备继续折腾
11:35:43 SQL> set autotrace on
11:35:58 SQL> select count(1) from trans_tmp;

  COUNT(1)
----------
   8997943

已用时间:  00: 02: 35.10

执行计划
----------------------------------------------------------
Plan hash value: 1765477136

----------------------------------------------------------------------------------------------------------------
| Id  | Operation              | Name             | Rows  | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |
----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT       |                  |     1 | 46879   (1)| 00:09:23 |        |      |         |
|   1 |  SORT AGGREGATE        |                  |     1 |            |          |        |      |         |
|   2 |   PX COORDINATOR       |                  |       |            |          |        |      |         |
|   3 |    PX SEND QC (RANDOM) | :TQ10000         |     1 |            |          |  Q1,00 | P->S | QC (RAND)  |
|   4 |     SORT AGGREGATE     |                  |     1 |            |          |  Q1,00 | PCWP |         |
|   5 |      PX BLOCK ITERATOR |                  |    11M| 46879   (1)| 00:09:23 |  Q1,00 | PCWC |         |
|   6 |       TABLE ACCESS FULL| TRANS_TMP |    11M| 46879   (1)| 00:09:23 |  Q1,00 | PCWP |         |
----------------------------------------------------------------------------------------------------------------


统计信息
----------------------------------------------------------
        273  recursive calls
          0  db block gets
     769352  consistent gets
     768853  physical reads
          0  redo size
        411  bytes sent via SQL*Net to client
        400  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          6  sorts (memory)
          0  sorts (disk)
          1  rows processed
并行扫描全表用时2分35，至少是比最开始快了一些

最后再次尝试一下bitmap

11:38:44 SQL> drop index trans_id;

索引已删除。

已用时间:  00: 00: 01.31
11:41:31 SQL> create bitmap index bitmap_id_idx on trans_tmp(id) online;
11:59:20 SQL> set autotrace trace exp
11:59:36 SQL> select count(1) from trans_tmp;
已用时间:  00: 00: 00.15

执行计划
----------------------------------------------------------
Plan hash value: 4075861796

---------------------------------------------------------------------------------------
| Id  | Operation                     | Name          | Rows  | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |               |     1 | 29563   (1)| 00:05:55 |
|   1 |  SORT AGGREGATE               |               |     1 |            |          |
|   2 |   BITMAP CONVERSION COUNT     |               |    11M| 29563   (1)| 00:05:55 |
|   3 |    BITMAP INDEX FAST FULL SCAN| BITMAP_ID_IDX |       |            |          |
---------------------------------------------------------------------------------------

11:59:41 SQL> alter index bitmap_id_idx parallel 4;

索引已更改。

已用时间:  00: 00: 00.23
11:59:55 SQL> select count(1) from trans_tmp;
已用时间:  00: 00: 00.23

执行计划
----------------------------------------------------------
Plan hash value: 3303238536

------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                         | Name          | Rows  | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |
------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                  |               |     1 |  8212   (1)| 00:01:39 |        |   |               |
|   1 |  SORT AGGREGATE                   |               |     1 |            |          |        |   |               |
|   2 |   PX COORDINATOR                  |               |       |            |          |        |   |               |
|   3 |    PX SEND QC (RANDOM)            | :TQ10000      |     1 |            |          |  Q1,00 | P->S | QC (RAND)  |
|   4 |     SORT AGGREGATE                |               |     1 |            |          |  Q1,00 | PCWP |            |
|   5 |      PX BLOCK ITERATOR            |               |    11M|  8212   (1)| 00:01:39 |  Q1,00 | PCWC |            |
|   6 |       BITMAP CONVERSION COUNT     |               |    11M|  8212   (1)| 00:01:39 |  Q1,00 | PCWP |            |
|   7 |        BITMAP INDEX FAST FULL SCAN| BITMAP_ID_IDX |       |            |          |  Q1,00 | PCWP |            |
------------------------------------------------------------------------------------------------------------------------

11:59:58 SQL> set autot on
12:00:12 SQL> select count(1) from trans_tmp;

  COUNT(1)
----------
   8997943

已用时间:  00: 03: 39.95

执行计划
----------------------------------------------------------
Plan hash value: 3303238536

------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                         | Name          | Rows  | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |
------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                  |               |     1 |  8212   (1)| 00:01:39 |        |   |               |
|   1 |  SORT AGGREGATE                   |               |     1 |            |          |        |   |               |
|   2 |   PX COORDINATOR                  |               |       |            |          |        |   |               |
|   3 |    PX SEND QC (RANDOM)            | :TQ10000      |     1 |            |          |  Q1,00 | P->S | QC (RAND)  |
|   4 |     SORT AGGREGATE                |               |     1 |            |          |  Q1,00 | PCWP |            |
|   5 |      PX BLOCK ITERATOR            |               |    11M|  8212   (1)| 00:01:39 |  Q1,00 | PCWC |            |
|   6 |       BITMAP CONVERSION COUNT     |               |    11M|  8212   (1)| 00:01:39 |  Q1,00 | PCWP |            |
|   7 |        BITMAP INDEX FAST FULL SCAN| BITMAP_ID_IDX |       |            |          |  Q1,00 | PCWP |            |
------------------------------------------------------------------------------------------------------------------------


统计信息
----------------------------------------------------------
        229  recursive calls
          0  db block gets
      34045  consistent gets
      32656  physical reads
          0  redo size
        411  bytes sent via SQL*Net to client
        400  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          6  sorts (memory)
          0  sorts (disk)
          1  rows processed
虽然cost很低，但是执行时间却很长，看来还是只能并行全表扫描了

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/25680865/viewspace-714224/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/25680865/viewspace-714224/

cnxfytscp521955115
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
数据库开发——MySQL——慢查询优化
01-07
一、正确使用索引 1.索引未命中 并不是说我们创建了索引就一定会加快查询速度，若想利用索引达到预想的提高查询速度的效果，我们在添加索引时，必须遵循以下问题 范围问题，或者说条件不明确，条件中出现这些符号或关键字：>、>=、<、<=、!= 、between…and…、like、 不等于！= between …and… like 2 尽量选择区分度高的列作为索引 区分度的公式是count(distinct col)/count(*)，表示字段不重复的比例，比例越大我们扫描的记录数越少，唯一键的区分度是1，而一些状态、性别字段可能在大数据面前区分度就是0。 那可能有人会问，这个比例有什么经验
Unveiling-the-ActiLife-Algorithm--Converting-Raw-Acceleration-Data-to-Activity-Count:2015年无线健康大会论文
05-16
揭示ActiLife算法-将原始加速数据转换为活动计数2015年无线健康大会论文论文“揭露ActiLife算法：将原始加速度数据转换为活动计数”将提交给Wireless Health2015。开源代码和数据被保存在Github中，供学者使用并提高...
基于Python实现通过人口分布数据进行绘制Matplotlib散点图（Scatter）【100010097】
12-14
详情介绍：https://www.yuque.com/sxbn/ks/100010097 1压缩文件（gpw-v4-population-count-rev11_2020_30_sec_asc.zip）是一个全球人口分布数据。基于 Sanic实现一个查询服务，服务包括： 按给定的经纬度范围查询人口总数，查询结果采用JSON格式。 不可以采用数据库，只允许使用文件方式存储数据。 可以对现有数据进行整理以便加快查询速度，尽量提高查询速度。 查询参数格式采用GeoJSON（https://geojson.org/）的多边形（每次只需要查询一个多边形范围，只需要支持凸多边形） 2针对上面的查询服务，实现一个服务查询客户端，数据获取后使用Matplotlib散点图（Scatter）进行绘制。 横坐标（x轴）为经度，纵坐标（y轴）为维度。
MySQL的count(*)查询太慢如何优化？
m0_72391097的博客
01-31 1465
MySQL的count(*)查询太慢如何去优化
MySQL超大表如何限制count最大数量，提高count速度
程序员阿超的博客
03-30 4465
在表中数据非常多的时候，如下count语句可能需要数秒时间 select count * from t_goods where xxx 我们可以通过限制count最大数量以提高查询速度，将查询速度控制在毫秒级，sql如下 select count(*) from( select 1 from t_goods where xxx limit 1000 ) temp 这种方式适用于对很大的...
MySQL实战45讲—— 14count(*)这么慢， 我该怎么办？
meser88的博客
10-27 3865
文章摘抄自林晓斌老师《MySQL实战45讲》。在开发系统的时候，你可能经常需要计算一个表的行数，比如一个交易系统的所有变更记录总数。这时候你可能会想，一条select count(*) from t 语句不就解决了吗？ 但是，你会发现随着系统中记录数越来越多，这条语句执行得也会越来越慢。然后你可能就想了，MySQL怎么这么笨啊，记个总数，每次要查的时候直接读出来，不就好了吗。 那么今天，我们就来聊聊count(*)语句到底是怎样实现的，以及MySQL为什么会这么实现。然后，我会再和你说说，如果应用中有这
MySQL InnoDB 存储引擎 count加速
yuanlanjun
03-02 103
SELECT COUNT(1) from table USE INDEX (UNIQUE KEY); 比 使用主键索引要快,我测试的是1000W生产环境数据,快了至少3倍..... EXPLAIN SELECT COUNT(1) from `order` USE INDEX (PRIMARY)\G; *************************** 1. row ***********...
MySQL Count(*)提速30倍
coolmsn8786的博客
04-22 325
MySQL InnoDB是索引组织表，如果根据主键大范围查询，效率非常低下。 因为主键索引中还包含数据,需要扫描大量的块。 这种场景，如果有一个二级索引，则可以极大的提升查询速度。 初始化实验数据(100W记录) ...
提升postgresql 的count查询速度
David Liu的博客
09-05 6918
https://www.oschina.net/translate/faster-postgresql-counting
数据库提高查询速度的方法
牛排煎黑椒的博客
01-05 2961
转载至 国家一级键盘手操作表演艺术家的博客： https://blog.csdn.net/zianY. 处理百万级以上的数据提高查询速度的方法： 1.应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。 2.对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。 3.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如： select id fro.
MySQL 异步查询提高查询速度
程序猿在武汉
10-16 3146
本文解决什么问题 什么是 MySQL 异步查询 MySQL 异步查询的优缺点 一个例子 异步查询功能 MySQLi 扩展提供了异步查询功能，需要使用 mysqlnd ( MySQL Native Driver ) 作为数据库的驱动。 mysqlnd 是 Zend 公司开发的 MySQL 数据库驱动，采用 PHP 开源协议，用于代替旧版的有 MySQL AB 公司（现 oracle) 开发的 li...
SQL效率提升之一些SQL编写建议并有效利用索引
12-15
1.日期属性列，不会因为有分秒差别而减慢查询速度 2. 使用LIKE比较进行查询时，如果模式以特定字符串如“abc%”开头，使用索引则会提高效率；如果模式以通配符如“%xyz”开头，则索引不起作用 3. OR会引起全表扫描，...
bupt python选项期末程设，基于经纬度绘制人口分布，前后端分离 ，sanic aiohttp
01-24
* 可以对现有数据进行整理以便加快查询速度，尽量提高查询速度。 ### 客户端 针对上面的查询服务，实现一个服务查询客户端，数据获取后使用Matplotlib散点图（Scatter）进行绘制。 * 横坐标（x轴）为经度。 * 纵...
mysql count做where条件_mysql count 带上 where 查询速度怎么优化
weixin_35755188的博客
02-07 2781
1 row in set, 1 warning (0.00 sec)这样的好处是写法简单，用的是 MySQL 自己的语法。缺点也有，大概有两点：1.sql_calc_found_rows 是全表扫。2. found_rows() 函数是语句级别的存储，有很大的不确定性，所以在 MySQL 主从架构里，语句级别的行级格式下，从机数据可能会不准确。不过行记录格式改为 ROW 就 OK。所以最大的缺点...
26. 基于视觉的道路识别技术的智能小车导航源代码.zip
06-02
1.智能循迹寻光小车(原埋图+PCB+程序).zip 2.智能循迹小车程序.zip 3.智能寻迹小车c程序和驱动.zip 4. 智能小车寻迹(含霍尔测連)c程序,zip 5.智能小车完整控制程序,zip 6.智能小车黑线循迹、避障、遥控实验综合程序,zip 7.智能小车测速+12864显示 C程序,zip 8. 智能小车(循迹、避障、遥控、测距、电压检测)原理图及源代码,zip 9.智能灭火小车,zip 10,智能搬运机器人程序.zip 11.智能arduino小车源程序,z1p 12.-种基于STM32的语音蓝牙智能小车,zip 13.循迹小车决赛程序,zip 14.循迹小车51程序(超声波 颜色识别 舵机 步进电机 1602).zip 15.寻光小车,zip 16.小车测速程序,zip 17.五路循迹智能小车c源码.zip 18.无线小车原理图和程序,zip 19.四驱智能小车资料包(源程序+原理图+芯片手册+各模块产品手册).zip 20.4WD小车安装教程及程序,z1p 21.四路红外循迹小车决赛程序,zip 22,适合初学者借鉴的arduino智能小车代码集合,zip 23.脑电波控制小车,zip 24.蓝牙智能避障小车,zip 25.基于树莓派监控小车源码.zip 26.基于视觉的道路识别技术的智能小车导航源代码,zip 27.基于STM32F407的超声波智能跟随小车,zip 28.基于arduino的蓝牙智能小车,zip.zip 29.基于51的蓝牙智能小车,zip 30.基于51单片机的红外遥控控制小车程序,zip
295_驾校预约管理系统的设计与实现-源码.zip
06-02
提供的源码资源涵盖了安卓应用、小程序、Python应用和Java应用等多个领域，每个领域都包含了丰富的实例和项目。这些源码都是基于各自平台的最新技术和标准编写，确保了在对应环境下能够无缝运行。同时，源码中配备了详细的注释和文档，帮助用户快速理解代码结构和实现逻辑。 适用人群： 这些源码资源特别适合大学生群体。无论你是计算机相关专业的学生，还是对其他领域编程感兴趣的学生，这些资源都能为你提供宝贵的学习和实践机会。通过学习和运行这些源码，你可以掌握各平台开发的基础知识，提升编程能力和项目实战经验。 使用场景及目标： 在学习阶段，你可以利用这些源码资源进行课程实践、课外项目或毕业设计。通过分析和运行源码，你将深入了解各平台开发的技术细节和最佳实践，逐步培养起自己的项目开发和问题解决能力。此外，在求职或创业过程中，具备跨平台开发能力的大学生将更具竞争力。 其他说明： 为了确保源码资源的可运行性和易用性，特别注意了以下几点：首先，每份源码都提供了详细的运行环境和依赖说明，确保用户能够轻松搭建起开发环境；其次，源码中的注释和文档都非常完善，方便用户快速上手和理解代码；最后，我会定期更新这些源码资源，以适应各平台技术的最新发展和市场需求。
price2016.csv
最新发布
06-02
price2016.csv
三层复式别墅-别墅结构.dwg
06-02
三层复式别墅—别墅结构.dwg
13. 循迹小车决赛程序.zip
06-02
1.智能循迹寻光小车(原埋图+PCB+程序).zip 2.智能循迹小车程序.zip 3.智能寻迹小车c程序和驱动.zip 4. 智能小车寻迹(含霍尔测連)c程序,zip 5.智能小车完整控制程序,zip 6.智能小车黑线循迹、避障、遥控实验综合程序,zip 7.智能小车测速+12864显示 C程序,zip 8. 智能小车(循迹、避障、遥控、测距、电压检测)原理图及源代码,zip 9.智能灭火小车,zip 10,智能搬运机器人程序.zip 11.智能arduino小车源程序,z1p 12.-种基于STM32的语音蓝牙智能小车,zip 13.循迹小车决赛程序,zip 14.循迹小车51程序(超声波 颜色识别 舵机 步进电机 1602).zip 15.寻光小车,zip 16.小车测速程序,zip 17.五路循迹智能小车c源码.zip 18.无线小车原理图和程序,zip 19.四驱智能小车资料包(源程序+原理图+芯片手册+各模块产品手册).zip 20.4WD小车安装教程及程序,z1p 21.四路红外循迹小车决赛程序,zip 22,适合初学者借鉴的arduino智能小车代码集合,zip 23.脑电波控制小车,zip 24.蓝牙智能避障小车,zip 25.基于树莓派监控小车源码.zip 26.基于视觉的道路识别技术的智能小车导航源代码,zip 27.基于STM32F407的超声波智能跟随小车,zip 28.基于arduino的蓝牙智能小车,zip.zip 29.基于51的蓝牙智能小车,zip 30.基于51单片机的红外遥控控制小车程序,zip
CockroachDB count 查询优化
05-25
CockroachDB 是一个分布式数据库系统，它采用了多副本分布式事务协议，以实现高可用性和数据强一致性。在 CockroachDB 中，查询优化是一个非常重要的问题，特别是在面对大量数据时。下面是一些 CockroachDB 中 count 查询优化的建议： 1. 使用索引：使用索引可以让 count 查询更快。当使用 count(*) 进行全表扫描时，CockroachDB 需要扫描整个表，导致查询速度变慢。但是，如果使用索引，则可以只扫描索引，而不是整个表。 2. 避免使用 DISTINCT：DISTINCT 会增加 count 查询的复杂度。如果可以避免使用 DISTINCT，则可以提高查询速度。 3. 使用 WHERE 子句：使用 WHERE 子句可以使查询更快。WHERE 子句可以限制查询的数据集，减少扫描的数据量。 4. 使用 COUNT(column)：如果只需要计算某个列的值，可以使用 COUNT(column) 代替 COUNT(*)。这样做可以减少扫描的数据量，从而提高查询速度。 5. 避免使用 OFFSET 和 LIMIT：使用 OFFSET 和 LIMIT 可以分页查询结果，但是对于大量数据来说，这样做可能会导致查询变慢。因此，尽可能避免使用 OFFSET 和 LIMIT。 6. 增加节点数量：如果集群中的节点数量越多，查询的并行度就越高，查询速度也就越快。因此，可以通过增加节点数量来提高查询速度。 总之，对于 count 查询的优化，需要综合考虑多个因素，如索引、WHERE 子句、DISTINCT、OFFSET 和 LIMIT 等。同时，增加节点数量也是提高查询速度的有效方法。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值