mysql踩坑之limit與sum函數(shù)混合使用問題詳解
前言
今天同事在同步完訂單數(shù)據(jù)后,由于訂單總金額和數(shù)據(jù)源的總金額存在差異,選擇使用LIMIT和SUM()函數(shù)計(jì)算當(dāng)前分頁的總金額來和對(duì)方比較特定訂單的總金額,卻發(fā)現(xiàn)計(jì)算出來的金額并不是分頁的訂單總金額,而是所有訂單的總金額。
數(shù)據(jù)庫版本為mysql 5.7,下面會(huì)用一個(gè)示例復(fù)盤遇到的問題。
問題復(fù)盤
本次復(fù)盤會(huì)用一個(gè)很簡(jiǎn)單的訂單表作為示例。
數(shù)據(jù)準(zhǔn)備
訂單表建表語句如下(這里偷懶了,使用了自增ID,實(shí)際開發(fā)中不建議使用自增ID作為訂單ID)
CREATE TABLE `order` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '訂單ID', `amount` decimal(10,2) NOT NULL COMMENT '訂單金額', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
插入金額為100的SQL如下(執(zhí)行10次即可)
INSERT INTO `order`(`amount`) VALUES (100);
所以總金額為10*100=1000。
問題SQL
使用limit對(duì)數(shù)據(jù)進(jìn)行分頁查詢,同時(shí)使用sum()函數(shù)計(jì)算出當(dāng)前分頁的總金額
SELECT SUM(`amount`) FROM `order` ORDER BY `id` LIMIT 5;
前面也提到了運(yùn)行的結(jié)果,期待的結(jié)果應(yīng)該為5*100=500,然而實(shí)際運(yùn)行的結(jié)果卻為1000.00(帶有小數(shù)點(diǎn)是因?yàn)閿?shù)據(jù)類型)
問題排查
其實(shí)如果對(duì)SELECT語句執(zhí)行順序有一定了解的朋友可以很快確定為什么返回的結(jié)果為所有的訂單總金額?下面我會(huì)就問題SQL的執(zhí)行書序來分析問題:
- FROM:FROM子句是最先執(zhí)行的,確定了查詢的是order這張表
- SELECT:SELECT子句是第二個(gè)執(zhí)行的子句,同時(shí)SUM()函數(shù)也在此時(shí)執(zhí)行了。
- ORDER BY:ORDER BY子句是第三個(gè)執(zhí)行的子句,其處理的結(jié)果只有一個(gè),就是訂單總金額
- LIMIT:LIMIT子句是最后執(zhí)行的,此時(shí)結(jié)果集中只有一個(gè)結(jié)果(訂單總金額)
補(bǔ)充內(nèi)容
這里補(bǔ)充一下SELECT語句執(zhí)行順序
- FROM <left_table>
- ON <join_condition>
- <join_type> JOIN <right_table>
- WHERE <where_condition>
- GROUP BY <group_by_list>
- HAVING <having_condition>
- SELECT
- DISTINCT <select_list>
- ORDER BY <order_by_condition>
- LIMIT <limit_number>
解決辦法
遇到需要統(tǒng)計(jì)分頁數(shù)據(jù)時(shí)(除了SUM()函數(shù)外,常見的COUNT()、AVG()、MAX()、MIN()函數(shù)也存在這個(gè)問題),可以選擇使用子查詢來處理(PS:這里不考慮內(nèi)存計(jì)算,針對(duì)的是使用數(shù)據(jù)庫解決這個(gè)問題)。上面的問題解決方案如下:
SELECT SUM(o.amount) FROM (SELECT `amount` FROM `order` ORDER BY `id` LIMIT 5) AS o;
運(yùn)行的返回值為500.00。
總結(jié)
以上就是這篇文章的全部?jī)?nèi)容了,希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,謝謝大家對(duì)腳本之家的支持。
相關(guān)文章
簡(jiǎn)單學(xué)習(xí)SQL的各種連接Join
sql語句中join是一種高效的語句,下面小編來帶大家詳細(xì)了解一下它的詳細(xì)情況2019-05-05Express連接MySQL及數(shù)據(jù)庫連接池技術(shù)實(shí)例
數(shù)據(jù)庫連接池是程序啟動(dòng)時(shí)建立足夠數(shù)量的數(shù)據(jù)庫連接對(duì)象,并將這些連接對(duì)象組成一個(gè)池,由程序動(dòng)態(tài)地對(duì)池中的連接對(duì)象進(jìn)行申請(qǐng)、使用和釋放,本文重點(diǎn)給大家介紹Express連接MySQL及數(shù)據(jù)庫連接池技術(shù),感興趣的朋友一起看看吧2022-02-02mysql去除重復(fù)數(shù)據(jù)只保留一條數(shù)據(jù)實(shí)例
這篇文章主要給大家介紹了關(guān)于mysql去除重復(fù)數(shù)據(jù)只保留一條數(shù)據(jù)的相關(guān)資料,在使用MySQL時(shí),有時(shí)需要查詢出某個(gè)字段不重復(fù)的記錄,文中通過示例代碼介紹的非常詳細(xì),需要的朋友可以參考下2023-08-08mysql5.7大量sleep進(jìn)程常規(guī)處理方式及配置示例
這篇文章主要給大家介紹了關(guān)于mysql5.7大量sleep進(jìn)程常規(guī)處理方式及配置的相關(guān)資料,sleep連接過多會(huì)嚴(yán)重消耗mysql服務(wù)器資源(主要是cpu,內(nèi)存),并可能導(dǎo)致mysql崩潰,需要的朋友可以參考下2023-08-08MySQL數(shù)據(jù)庫執(zhí)行Update卡死問題的解決方法
最近開發(fā)的時(shí)候debug到一條update的sql語句時(shí)程序就不動(dòng)了,然后我就在plsql上試了一下,發(fā)現(xiàn)plsql一直在顯示正在執(zhí)行,等了好久也不出結(jié)果,下面這篇文章主要給大家介紹了關(guān)于MySQL數(shù)據(jù)庫執(zhí)行Update卡死問題的解決方法,需要的朋友可以參考下2022-05-05