Photo by Iga Palacz on Unsplash
最近解決了一個生產 SQL 慢查詢的問題，排查問題之後發現一些比較隱匿且容易忽略的問題。
業務背景介紹
最近業務上需要上線一個預警功能，需要查出一段時間內交易，求出當前交易成功率。當成功率低於設定閾值時，短信預警。業務邏輯很簡單，測試環境測試也沒問題之後，部署上線。實際生產運行時卻發現每次 SQL 查詢需要花費 60 多秒。
系統架構介紹
Spring boot + Mybatis + Oracle。
需要查詢的表數量級爲億級。
排查問題
交易表結構(已經簡化)大致如下。
create table TB_TEST
(
BANK_CODE VARCHAR2(20),
CREATE_TIME DATE,
OID_BILL NUMBER(16) not null
)
/
create index TB_TEST_CREATE_TIME_INDEX
on TB_TEST (CREATE_TIME)
/
create unique index TB_TEST_OID_BILL_UINDEX
on TB_TEST (OID_BILL)
/
alter table TB_TEST
add constraint TB_TEST_PK
primary key (OID_BILL)
/
該項目的增刪改查語句使用 MybatisGenerate 自動生成，查詢語句使用 CREATE_TIME 做爲條件查詢，自動生成 sql 如下。
select *
from TB_TEST
where CREATE_TIME >= #{start_time}
and CREATE_TIME < #{end_time};
我們通過設置 Druid 的配置，將具體查詢 SQL 日誌輸出到控制檯。具體設置如下。
<bean id="dataSource" class="com.alibaba.druid.pool.DruidDataSource" init-method="init" destroy-method="close">
... ...
<property name="filters" value="stat,slf4j" />
</bean>
<!-- logback -->
<logger name="druid.sql.Statement" level="DEBUG" additivity="false">
<appender-ref ref="STDOUT"/>
</logger>具體 sql 日誌如下：
從日誌中我們可以清楚看到實際運行的 SQL，以及查詢參數與類型。
從查詢語句看來，我們查詢條件正確，且由於 CREATE_TIME 存在獨立索引，所以查詢會走索引，查詢速度應該很快，不至於每次查詢需要花費 60 多秒。
所以當時猜測這次查詢由於某些原因發生了全表掃描，未走索引才導致慢查詢。在 Google 搜索相關資料，看見一篇文章 https://www.cnblogs.com/chen-...。
根據文章描述的是 Oracle 中存在隱式轉換的情況，當類型不匹配的時，Oracle 會主動將類型轉換成目標類型。查看我們表結構，CREATE_TIME 爲 Date 類型，而根據日誌我們查詢參數傳遞的 CREATE_TIME 卻爲 TIMESTAMP 類型。
所以實際在數據庫查詢 SQL 如下：
SELECT *
FROM TB_TEST
WHERE (CREATE_TIME >= to_timestamp('2018-03-03 18:45:32', 'yyyy-mm-dd hh24:mi:ss') and
CREATE_TIME < to_timestamp('2019-01-03 18:45:32', 'yyyy-mm-dd hh24:mi:ss'));
可能這裏發生一次隱式轉換。
如何證明這個猜想那？我們可以使用 EXPLAIN PLAN ，分析 SQL 執行計劃.上面 SQL 執行計劃如下。
從上圖我們可以從 TB ACCESS FULL 看出，這次查詢慢確實由於是全表掃描導致。
然後我們查看執行計劃中的 Predicate Information 信息，Oracle 使用 INTERNAL_FUNCATIPON 轉換 CREATE_TIME 類型 。從這點那可以看出查詢過程索引字段發生一次內聯函數轉換。
SQL 性能優化往往會有一點，避免在索引字段使用函數。
既然知道原因，那麼解決辦法也沒有這麼難了。我們將查詢 sql 改爲如下就能解決。
select *
from TB_TEST
where CREATE_TIME >= TO_DATE(#{start_time}, 'yyyy-mm-dd hh24:mi:ss')
and CREATE_TIME < TO_DATE(#{end_time}, 'yyyy-mm-dd hh24:mi:ss');
-- 或者使用 cast 函數
select *
from TB_TEST
where CREATE_TIME >= cast(#{start_time} as date)
and CREATE_TIME < cast(#{end_time} as date);分析原因
解決完問題，我們分析下 Java 類型中的 Date 類型爲什麼最終會轉換成 Oracle 中的 TIMESTAMP 類型。
這次案例中我們使用 Mybatis 框架，框架內部會將 Java 數據類型轉換成對應的 JDBC 數據類型。查看Mybatis 類型轉換 這一節我們可以發現 Java Date 類型將會轉換成 java.sql.TIMESTAMP。
然後我們查看 Oracle JDBC 數據類型轉換規則。在 https://docs.oracle.com/cd/B1... 我們可以看到，TIMESTAMP 將轉換成 Oracle 中 TIMESTAMP。
問題擴展
假設我們將 CREATE_TIME 類型修改成 TIMESTAMP，然後查詢的時候將 CREATE_TIME 轉換成 Date 類型，是否也會發生內聯函數轉換，然後導致全表掃描那？查詢 sql 如下。
-- CREATE_TIME 類型爲 TIMESTAMP
select *
from TB_TEST
where CREATE_TIME >= TO_DATE('2018-02-27 19:36:21', 'yyyy-mm-dd hh24:mi:ss')
and CREATE_TIME < TO_DATE('2018-12-27 19:36:21', 'yyyy-mm-dd hh24:mi:ss')
。。。。
。。。。
。。。。
我們用 EXPLAIN PLAN 分析這個 SQL。
我們可以看到，確實發生了一次內聯轉化，但是卻在另外一邊。這次查詢走的是索引。
從這個例子我們可以看出，在索引字段上使用函數會導致全表掃描。但是在傳入查詢參數上使用函數並不會導致索引失效。
總結
1 SQL 查詢時需要注意兩邊數據類型的一致性，雖然數據庫隱式轉換會幫我們解決數據不一致的問題，但是這種隱式轉化帶來一些隱蔽問題，讓我們第一時間並不能很快發現。所以使用顯示轉換代替隱式轉換。這樣我們的 SQL 清晰易懂，而且更加可控。
2 學會使用 EXPLAIN PLAN 分析慢 SQL。
3 索引字段上使用相關函數會導致慢查詢，查詢時切勿在索引字段上使用函數。
參考文檔
1、 https://docs.oracle.com/cd/B1...
2、 https://dev.mysql.com/doc/ref...
如果覺得好的話，請幫作者點個讚唄~ 謝謝
喜歡本文的讀者們，歡迎長按關注訂閱號程序通事~讓我與你分享程序那些事。
