phoenix 有时候不走二级索引 会 更快 /*+ NO_INDEX*/

最新推荐文章于 2022-10-11 22:21:28 发布
原创 最新推荐文章于 2022-10-11 22:21:28 发布 · 1.9k 阅读 · 2 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文探讨了在Phoenix数据库中，如何通过禁用二级索引优化特定SQL查询效率的案例。通过对查询计划的分析，展示了在结果集较小的情况下，直接使用row key进行查询比使用二级索引更为高效。 
0: jdbc:phoenix:192.168.199.154> select t1.seq_id as seq_id from (select seq_id,toy from T_EXTENSION_SHOW where show_date='2018-11-24' and email='wjc@45555.com') t1 where t1.toy='ambi' and t1.cam_site='cam4' order by t1.seq_id desc limit 1;
+---------+
| SEQ_ID  |
+---------+
| 45555   |
+---------+
1 row selected (0.663 seconds)


0: jdbc:phoenix:192.168.199.154> explain select t1.seq_id as seq_id from (select seq_id,toy from T_EXTENSION_SHOW where show_date='2018-11-24' and email='wjc@45555.com') t1 where t1.toy='ambi' and t1.cam_site='cam4' order by t1.seq_id desc limit 1;
+--------------------------------------------------------------------------------------------------------------------------------------------+-----------------+----------------+----------------+
|                                                                    PLAN                                                                    | EST_BYTES_READ  | EST_ROWS_READ  |  EST_INFO_TS   |
+--------------------------------------------------------------------------------------------------------------------------------------------+-----------------+----------------+----------------+
| CLIENT 1-CHUNK 4309216 ROWS 314572800 BYTES PARALLEL 1-WAY RANGE SCAN OVER IDX_T_EXTENSION_SHOW_CAM_SITE_TOY ['2018-11-24','cam4','ambi']  | 314572800       | 4309216        | 1543840687850  |
|     SERVER FILTER BY FIRST KEY ONLY AND "EMAIL" = 'wjc@45555.com'                                                                          | 314572800       | 4309216        | 1543840687850  |
|     SERVER 1 ROW LIMIT                                                                                                                     | 314572800       | 4309216        | 1543840687850  |
| CLIENT 1 ROW LIMIT                                                                                                                         | 314572800       | 4309216        | 1543840687850  |
+--------------------------------------------------------------------------------------------------------------------------------------------+-----------------+----------------+----------------+
4 rows selected (0.082 seconds)

分析上面的sql，查询条件中email是最细粒度，查出来就1条数据。row key是由show_date + email + seq_id组成的。

phoenix自动优化，使用了二级索引IDX_T_EXTENSION_SHOW_CAM_SITE_TOY ，反而降低了查询效率。

 

实际上我不希望sql走二级索引，希望SQL走自带的row key，进行查询。可以这样做。

0: jdbc:phoenix:192.168.199.154> select /*+ NO_INDEX*/ t1.seq_id as seq_id from (select seq_id,toy from T_EXTENSION_SHOW where show_date='2018-11-24' and email='wjc@45555.com') t1 where t1.toy='ambi' and t1.cam_site='cam4' order by t1.seq_id desc limit 1;
+---------+
| SEQ_ID  |
+---------+
| 45555   |
+---------+
1 row selected (0.046 seconds)


0: jdbc:phoenix:192.168.199.154> explain select /*+ NO_INDEX*/ t1.seq_id as seq_id from (select seq_id,toy from T_EXTENSION_SHOW where show_date='2018-11-24' and email='wjc@45555.com') t1 where t1.toy='ambi' and t1.cam_site='cam4' order by t1.seq_id desc limit 1;
+-----------------------------------------------------------------------------------------------------------------------+-----------------+----------------+--------------+
|                                                         PLAN                                                          | EST_BYTES_READ  | EST_ROWS_READ  | EST_INFO_TS  |
+-----------------------------------------------------------------------------------------------------------------------+-----------------+----------------+--------------+
| CLIENT 1-CHUNK 0 ROWS 0 BYTES PARALLEL 1-WAY REVERSE RANGE SCAN OVER T_EXTENSION_SHOW ['2018-11-24','wjc@45555.com']  | 0               | 0              | null         |
|     SERVER FILTER BY (TOY = 'ambi' AND CAM_SITE = 'cam4')                                                             | 0               | 0              | null         |
|     SERVER 1 ROW LIMIT                                                                                                | 0               | 0              | null         |
| CLIENT 1 ROW LIMIT                                                                                                    | 0               | 0              | null         |
+-----------------------------------------------------------------------------------------------------------------------+-----------------+----------------+--------------+
4 rows selected (0.126 seconds)

结果集够小的情况，FILTER BY很快。

0.663s VS 0.046s

 

END

 

 

 

Phoenix填坑记1：索引无故被disable
sunlen的专栏(编程技术探讨)
12-29 1336
Phoenix是基于HBase的，而Phoenix的索引其实是HBase的二级索引，当Phoenix的索引处于disable状态时，整个Phoenix表是无法正常使用的，要将索引修复为enable状态，往往需要重建索引，这对应一些大表来说，往往需要花费几个小时是时间，那么这几个小时，系统基本上就处于不可用状态，这对应现网系统来说，往往是不可接受的。 其实Phoenix有3个隐藏参数，这些参数在官网文档没有体现，但实际上这3个参数非常重要，可以解决上面提到的问题。 闲话不说，先来讲...
Linux 性能优化之CPU 多级缓存
山河已无恙
09-30 1961
博文内容为 Linux CPU 多级缓存认知内容涉及：什么是CPU多级缓存认知，CPU 硬件缓存信息，缓存流程写入策略，映射算法认知CPU 缓存分析，使用 valgring 和 Perf 分析CPU 缓存命中情况编码方面 CPU 缓存优化，数据指令缓存，多核缓存命中率优化方式理解不足小伙伴帮忙指正 😃,生活加油哦99%的焦虑都来自于虚度时间和没有好好做事，所以唯一的解决办法就是行动起来，认真做完事情，战胜焦虑，战胜那些心里空荡荡的时刻，而不是选择逃避。
Phoenix系列：二级索引（2）
weixin_33963594的博客
01-08 202
上一篇介绍了Phoenix基于HBase的二级索引的基本知识，这一篇介绍一下和索引相关的一致性和优化相关内容。 一致性的保证 Phoenix客户端在成功提交一个操作并且得到成功响应后，就代表你所做的操作已经成功应用到原表和相关的索引表中。换句话说，索引表的维护和处理原表数据是同步的，并且各自是强一致性保证的。但是因为索引表和原表是在不同的表中，根据表的属性和索引的类型，当服务端崩溃导致一次提交...
【HINT】使用“NO_INDEX ”Hint提示避免SQL使用特定索引
cuanchuwei1207的博客
05-04 2470
在生产环境的SQL调优测试过程中经常遇到如下场景：一张表上创建了非常多的索引（不推荐），每一个索引都是针对特定业务查询而增加的。这极易导致SQL由于个别索引的引入出现性能问题，在这种情况下不能简简单单的将索引删除在...
phoenix的全局索引不起作用原因分析
XDSXHDYY的博客
09-19 1641
phoenix的全局索引没起作用 phoenix里面的全局索引比较废柴， 因为除了select count(*) from table where name=‘xd’ 这种写法会用到索引之外，其他的情况都用不到这个全局索引 包括 select * from table where name='xd’也用不到索引，而是进行full scan。 原因分析 这一点和我们平时的sql索引原理有点不一样，普...
记一次phoenix在不加索引的情况调优，由6s以上时间变成不到1s
08-20 487
背景： 网约车预约单查询： 这里面恶心的地方是： 1个时间窗口要查询6种时间：推送订单时间（来自mongodb）、有效抢单时间（来自mongodb）、抢单成功时间（实时kafka）、取消订单时间（实时kafka）、到达目的地时间（实时kafka）、支付时间（实时kafka） 根据现实的业务情况，乘客即便打车了，也不是立马支付，很可能过些天才支付。所以不能做表关联，否...
phoenix入门
洛云凡
10-25 1688
1、为什么使用Phoenix phoenix，由saleforce.com开源的一个项目，后又捐给了Apache。它相当于一个Java中间件，帮助开发者，像使 用jdbc访问关系型数据库一些，访问NoSql数据库HBase。 phoenix，操作的表及数据，存储在hbase上。phoenix只是需要和Hbase进行表关联起来。然后再用工具进行一些读或写操作。 其实，可以把Phoenix只看成一种代...
hadoop：hbase：apache-phoenix连接hbase，实现类sql查询（附DBeaver连接方式）
不花的花和尚的博客
08-21 2682
学校
Phoenix（凤凰）安装部署及介绍
热门推荐
weixin_44524441的博客
01-07 3万+
Phoenix介绍 phoenix，中文译为“凤凰”，很美的名字。Phoenix是由saleforce.com开源的一个项目，后又捐给了Apache基金会。它相当于一个Java中间件，提供jdbc连接，操作hbase数据表。Phoenix是一个HBase的开源SQL引擎。你可以使用标准的JDBC API代替HBase客户端API来创建表，插入数据，查询HBase数据。 支持SQL的还有Hive和I...
大数据技术之HBase原理与实战归纳分享-下
itxiaoshen博客
10-11 1030
上一篇对Hbase底层原理有一定理解后则进入生产开发实战，企业开发大都使用Phoenix来操作Hbase的数据，先部署Phoenix，通过其类似shell命令工具创建表和插入数据及查询数据、表映射，简易JDBC演示示例，实操理解二级索引使用，最后通过整合Hive若干示例实现对Hbase的数据的简易分析能力。
Oracle Index索引无效的原因与解决方法
12-15
索引无效原因 最近遇到一个Oracle SQL语句的性能问题，修改功能之前的运行时间平均为0.3s，可是添加新功能后，时间达到了4~5s。虽然几张表的数据量都比较大（都在百万级以上），但是也都有正确创建索引，不知道到底慢在了哪里，下面展开调查。 经过几次排除，把问题范围缩小在索引上，首先在确定索引本身没有问题的前提下，考虑索引有没有被使用到，那么新的问题来了，怎么知道指定索引是否被启用。 判断索引是否被执行 1. 分析索引 即将索引至于监控状态下，对索引进行分析。如下对 ID_TT_SHOHOU_HIST_002 索引进行分析 alter index ID_TT_SHOHOU_HIST_
Oracle hint
05-19
在SQL优化过程中常见HINT的用法(前10个比较常用, 前3个最常用)： 1. /*+ INDEX */ 和 /*+ INDEX(TABLE INDEX1, index2) */ 和 /*+ INDEX(tab1.col1 tab2.col2) */ 和 /*+ NO_INDEX */ 和 /*+ NO_INDEX(TABLE INDEX1, index2) */ 2. /*+ ORDERED */ 3. /*+ PARALLEL(table1,DEGREE) */ 和 /*+ NO_PARALLEL(table1) */
Mysql 查询优化成本的计算，索引一定快？
qrn196789910的博客
12-06 613
在一些Mysql的面试题中，一定会问到Mysql优化的问题，可能大部分人都会回答，加索引就可以解决，查询慢的问题，那么接下来别人可能又会问到，那索引是不是加的越多越好呢，或者说索引是不是什么字段都可以加，什么字段不应该加呢，又或者说为什么有些查询明明加了索引还是慢呢？今天来说说mysql是如何计算查询优化的成本的。 一.计算全表扫描的代价 计算全部扫描需要2个重要的数据： 1.聚簇索引占用的页面数 2.表中的记录数 这两数使用 SHOW TABLE STATUS LIKE ‘single_table’ (s
phoenix索引
ac5248的博客
02-24 450
转发自 https://blog.youkuaiyun.com/bingoxubin/article/details/85023299 1. 介绍 二级索引这个特性应该是大部分用户引入Phoenix主要考虑的因素之一。HBase因其历史原因只支持rowkey索引，当使用rowkey来查询数据时可以很快定位到数据位置。现实中，业务查询需求条件往往比较复杂，带有多个查询字段组合，如果用HBase查的话，只能全表扫描进行过滤，效率很低。而Phoenix支持除rowkey外的其它字段的索引创建，即二级索引，查询效率可大
oracle hint_no_index
12-21 1427
oracle hint系列9no_index1,如果指定了表中一个索引,表中其它索引仍可选用2,如果指定了表中所有的索引,不会使用表中所有的索引3,如果未指定索引,不会使用表中所有的索引,即会走此表的全表扫描...
select index oracle,Oracle – 了解no_index提示
weixin_36453829的博客
04-03 376
我试图了解no_index如何实际加速查询并且无法在线查找文档来解释它.例如,我的查询速度非常慢select *from where field1_ like '%someGenericString%' andfield1_ <> 'someSpecificString' andAction_='_someAction_' andTimestamp_ >= trunc...
phoenix 创建索引
wumiqing1的博客
12-28 2585
需求：phoenix查询很慢的时候需要创建索引 问题： CREATE INDEX iupt ON webmagic_n.ENVIRONMENTAL_STATION_DATA2(update_time DESC) ; 错误： Error: ERROR 1029 (42Y88): Mutable secondary indexes must have the hbase.regionser...
oracle中no_index的使用,多个表no_index提示怎么写？
weixin_39833429的博客
04-05 1037
SQL> selectcount(*) from a1,a2,a32where a1.object_id=13and a2.object_id=1and a3.object_id=1and a1.object_name=a2.object_nameand a1.object_name=a3.object_name;4 5 6COUNT(*)----------0Exe...
phoenix存量数据过大导致建立索引超时问题解决
weixin_33775582的博客
01-24 2020
建立索引的时候耗了很长时间（十分钟左右），然后就报超时了 查看表清单的时候，发现那个索引表处于building之中 ...
namespace phoenix { namespace ad_msg { /** * @brief target trajectory status */ enum class TarTrajectoryStatus { INVALID = 0, CRUISING, BYPASSING }; /** * @brief 规划状态字 */ enum class PlanStatus : uint8_t { PLANNING_OK = 0, /** <规划成功 */ INIT_FAILED = 1, /** <初始化失败 */ PLANNING_FAILED = 2, /** <规划失败 */ PLANNING_FINISH = 3, /** <规划完成 */ PLANNING_NOT_UPDATE = 4, /** <规划轨迹不更新 */ PLANNING_BLOCKING = 5, /** <规划阻塞状态 */ }; /** * @brief紧急制动状态 */ enum class EmergencyStatesStop : uint8_t { IDLE = 0, ///**<IdleNo Braking */ COMFORTABLE = 1, ///**<Comfortable */ EMERGENCY = 2, ///**<Emergency */ RESERVED = 3, ///**<Reserved */ }; /** * @brief巡航规划算法输出 */ struct PlanningOutPut { uint32_t point_num; /**< 轨迹点个数 */ uint32_t seg_num; /**< 轨迹段数 */ uint32_t seg_start_pos[20]; /**< 每段轨迹起点在总轨迹的索引 */ uint32_t seg_end_pos[20]; /**< 每段轨迹终点在总轨迹的索引 */ float x[MAX_CRUISE_PLANNING_POINT]; /**< 轨迹点坐标x值，单位为米 */ float y[MAX_CRUISE_PLANNING_POINT]; /**< 轨迹点坐标x值，单位为米 */ float z[MAX_CRUISE_PLANNING_POINT]; /**< 轨迹点坐标z值，单位为米 */ float pitch[MAX_CRUISE_PLANNING_POINT]; /**< 轨迹点俯仰角的值，单位为弧度 */ float roll[MAX_CRUISE_PLANNING_POINT]; /**< 轨迹点横滚角的值，单位为弧度 */ float yaw[MAX_CRUISE_PLANNING_POINT]; /**< 轨迹点航向角的值，单位为弧度 */ float kappa[MAX_CRUISE_PLANNING_POINT]; /**< 轨迹点曲率的值 */ float dir[MAX_CRUISE_PLANNING_POINT]; /**< 轨迹点方向的值 */ float speed[MAX_CRUISE_PLANNING_POINT]; /**< 轨迹点速度 */ float a[MAX_CRUISE_PLANNING_POINT]; /**<轨迹点加速度 */ float s[MAX_CRUISE_PLANNING_POINT]; /**<轨迹点累计位移 */ PlanStatus planning_status; /**< 规划状态 */ TarTrajectoryStatus tar_trajectory_status; /**< target trajectory status */ EmergencyStatesStop emergency_states; ///< 紧急制动状态 }; } } syntax = "proto2"; package phoenix.msg.planning; // 目标轨迹状态 enum TarTrajectoryStatus { INVALID = 0; CRUISING = 1; // 自动分配的连续值需显式声明 BYPASSING = 2; } // 紧急状态信息 enum EmergencyStatesStop { IDLE = 0; ///< 空闲（无制动） COMFORTABLE = 1; ///< 舒适制动 EMERGENCY = 2; ///< 紧急制动 RESERVED = 3; ///< 保留状态 } // 规划状态字 enum PlanStatus { PLANNING_OK = 0; ///< 规划成功 INIT_FAILED = 1; ///< 初始化失败 PLANNING_FAILED = 2; ///< 规划失败 PLANNING_FINISH = 3; ///< 规划完成 PLANNING_NOT_UPDATE = 4; ///< 规划轨迹不更新 PLANNING_BLOCKING = 5; ///< 规划阻塞状态 } // 巡航规划算法输出 message OutDataCruiseTrajPlanning { required uint32 point_num = 1; ///< 轨迹点个数 required uint32 seg_num = 2; ///< 轨迹段数 // 段索引数组（固定长度20） repeated uint32 seg_start_pos = 3 ; //max_size = 20 repeated uint32 seg_end_pos = 4 ; //max_size = 20 // 轨迹点数据数组 (proto2中需显式声明packed) repeated float x = 5 [packed = true]; ///< x坐标（米） repeated float y = 6 [packed = true]; ///< y坐标（米） repeated float z = 7 [packed = true]; ///< z坐标（米） repeated float pitch = 8 [packed = true]; ///< 俯仰角（弧度） repeated float roll = 9 [packed = true]; ///< 横滚角（弧度） repeated float yaw = 10 [packed = true]; ///< 航向角（弧度） repeated float kappa = 11 [packed = true]; ///< 曲率 repeated float dir = 12 [packed = true]; ///< 方向 repeated float speed = 13 [packed = true]; ///< 速度 // 状态字段（必需字段） required PlanStatus planning_status = 14; ///< 规划状态 required TarTrajectoryStatus tar_trajectory_status = 15; ///< 绕障状态 required EmergencyStatesStop emergency_states = 16; ///< 紧急停车状态 } 实现bool ParseProtoMsg::EncodePlanningResultMessage( const phoenix::ad_msg::PlanningOutPut &msg, phoenix::msg::planning::OutDataCruiseTrajPlanning *const data_out) 其中msg为输入，data_out为输出
最新发布
11-07
我们需要将C++结构体phoenix::ad_msg::PlanningOutPut转换为protobuf消息phoenix::msg::planning::OutDataCruiseTrajPlanning 注意：输入结构体中的数组是固定大小的（例如x[MAX_CRUISE_PLANNING_POINT]），而...
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值