Ⅰ 為什麼sql過長會執行失敗，舉一個案例
1、不同的資料庫應該是不一樣的
2、不過任何東西不可能完全沒有限制，所以sql過長會失敗是肯定的。
3、以Mysql為例，在其配置文件中有一個設置 max_allowed_packet = 1M 此時如果你的SQL長度超過了1M就會被截斷，從而導致執行失敗。
Ⅱ 怎麼查找一次執行時間最長的SQL
執行時間最長的20條SQL語句（按時間降序排列），可保存為腳本方便調用：
SELECT rows_read / (num_executions + 1) as avg_rows_read,
rows_written / (num_executions + 1) as avg_rows_written,
stmt_sorts / (num_executions + 1) as avg_sorts,
total_exec_time / (num_executions + 1) as avg_exec_time,
substr(stmt_text,1,1000) as SQL_Stmt
FROM SYSIBMADM.SNAPDYN_SQL ORDER BY avg_exec_time desc fetch first 20 rows only;
祝你學習愉快！
Ⅲ 「oracle 10g」中怎樣執行很長的sql語句呢
lv_sql clob;--很長長很長的字元串 4G ，記住太長不能後在plsql不能列印，不能to_char,只要執---行就可以了，想要看結果可以寫入一個表欄位位clob，再select查看。
X number; --聲明變數
BEGIN
x:=1; --給初值
FOR X IN REVERSE 1..10000 LOOP --reverse由大到小
lv_sql :=lv_sql || 'insert into testtable (aa) values(''111'')'|| ';'；
END LOOP;
execute immediate lv_sql;
END;
---可以拼接可以很長很長,希望能幫到大家，然後點個贊，讓更多的人知道
Ⅳ VB執行SQL語句耗時太久導致程序假死怎麼處理
不管是用存儲過程還是直接用SQL語句，大數據量操作都會造成假死，可以嘗試以下思路：
將一次性執行分成多次執行，比如全表替換，為了較好的用戶體驗，可以逐行替換，然後在循環里加DoEvents配合顯示一個進度條。
或者，使用VB多線程技術（如ActiveXEXE）非同步執行，主線程循環中加DoEvents等待執行數據操作的線程結束的信息。
或者，使用SQLSERVER2005以上版本支持的ServiceBroker，構建一個非同步信息，在信息接收端執行數據操作，具體步驟可GOOGLE網站的SQLSERVER非同步觸發器。
附：
非同步執行就不會假死了,不過執行未完時最好不要作對這個過程有影響的操作.
PrivateWithEventsCssAsADODB.Connection
'''''''
Css.Execute"updatetable1seta='x',b='y'",,adAsyncExecute
PrivateSubcss_ExecuteComplete(ByValRecordsAffectedAsLong,ByValpErrorAsADODB.Error,adStatusAsADODB.EventStatusEnum,ByValpCommandAsADODB.Command,ByValpRecordsetAsADODB.Recordset,ByValpConnectionAsADODB.Connection)
OnErrorGoToEE
MsgBox"更新完畢."
Css.Close:SetCss=Nothing
ExitSub
EE:
SetCss=Nothing
EndSub
Ⅳ 多條SQL查詢程序運行時間過長
執行時間最長的20條SQL語句（按時間降序排列），可保存為腳本方便調用：
SELECT rows_read / (num_executions + 1) as avg_rows_read,
rows_written / (num_executions + 1) as avg_rows_written,
stmt_sorts / (num_executions + 1) as avg_sorts,
total_exec_time / (num_executions + 1) as avg_exec_time,
substr(stmt_text,1,1000) as SQL_Stmt
FROM SYSIBMADM.SNAPDYN_SQL ORDER BY avg_exec_time desc fetch first 20 rows only;
祝你學習愉快！
Ⅵ linux mysql 怎麼找到mysql用時最長的sql語句或者處於等待的sql語句
SQL長並不代表執行的慢，估計你真正要找的是執行代價最高的SQL。
執行show processlist, 看Time列時間最長，並且state處於執行狀態的SQL就可以找到慢查詢。 如果想幹掉這個慢查詢，可以把相應的SQL的id找出來， 然後kill id
Ⅶ 2020-10-11：一條sql語句執行時間過長，應該如何優化從哪些方面進行優化
改進資料庫sql語句進行優化的理由 應用程序之優化通常可分為兩個方面：源代碼之優化和sql語句之優化。源代碼之優化在時間成本和風險上代價很高；另一方面，源代碼之優化對資料庫系統性能之提升收效有限。 優化之理由 1)sql語句是對資料庫(數據)進行操作之惟一途徑； 2)sql語句消耗了70%~90%之資料庫資源； 3)sql語句獨立於程序設計邏輯，相對於對程序源代碼之優化，對sql語句之優化在時間成本和風險上之代價都很低； 4)sql語句可以有不同之寫法； 5)sql語句易學，難精通。 優化技術之發展 第一代之sql優化工具是執行計劃分析工具。這類之工具對輸入之sql語句從資料庫提取執行計劃，並解釋執行計劃中關鍵字之含義；第二代之sql優化工具只能提供增加索引之建議，它通過對輸入之sql語句之執行計劃之分析來產生是否要增加索引之建議。該類工具存在著致命之缺點——只分析了一條sql語句就得出增加某個索引之結論，根本不理會(實際上也無法評估到)增加之索引對整體資料庫系統性能之影響。其破壞性在於： 1、不理會增加之索引對其他增、刪、改sql語句之負面影響； 2、沒有考慮增加之索引可能導致資料庫判斷失誤； 3、對由於增加索引引起之資料庫系統負擔忽略不計。 同時，這些工具由於技術水平之限制存在著以下缺點： 1、無法保證建議或改寫之正確性； 2、無法進行重寫，僅僅提供了建議或有限程度之改寫，重寫工作還是需要人工完成，優化工作所需之時間和工作量同人工進行優化差不多； 3、改寫之規則和hints有限，難以處理復雜之sql語句； 4、必須人手逐條進行測試。 這類工具曾經盛極一時，直到人工智慧自動sql優化之出現。