MySQL 存儲進程中履行靜態SQL語句的辦法。本站提示廣大學習愛好者：（MySQL 存儲進程中履行靜態SQL語句的辦法）文章只能為提供參考，不一定能成為您想要的結果。以下是MySQL 存儲進程中履行靜態SQL語句的辦法正文
drop PROCEDURE if exists my_procedure;
create PROCEDURE my_procedure()
BEGIN
declare my_sqll varchar(500);
set my_sqll='select * from aa_list';
set @ms=my_sqll;
PREPARE s1 from @ms;
EXECUTE s1;
deallocate prepare s1;
end;
��
經由過程在辦事器上檢查數據庫的日記文件，發明存在年夜量的query notification dialog的信息，並且湧現的頻率異常的高，招致日記文件增年夜異常快。
經由過程谷歌懂得到這個毛病跟service broker的新聞機制由關系，可以經由過程應用跟蹤標志：DBCC TraceOn(4133,-1)可清除此信息。
不外如今確當務之急是若何清失落這些日記信息，最簡略的方法就是到SQL的日記目次中刪除這些日記文件便可，不外斟酌到刪除之前須要停滯SQL Server辦事，能夠會招致緩存中的數據喪失，是以，這不是推舉的做法。
那末准確的做法應當如何呢？
履行以下語句：
EXEC sp_cycle_errorlog;
每履行一次SQL會主動初始化一個日記文件，將日記的內容清空，當SQL有7個日記文件時（默許），請履行7次該操作，每次會將日記文件時光最老誰人清空。
讀者不用擔憂清空會消費很長的時光，我這邊的有個日記有40G，敕令履行完後，該文件立刻清空了。在時光緊迫的情形，這類方法尤其便利。
那末有無方法設置每一個日記文件的固定年夜小呢？
查過這方面的材料，有人說可以在注冊表中設置ErrorLogSizeInKb的年夜小，不外僅限於SQL2012，其他版本的數據庫設置後不失效，這個我沒有驗證過，有興致的同伙可以一路評論辯論下。
數據庫���日記報錯恢復
形成緣由,客戶的SqlServer為2000版本,因為日記過年夜無人治理,沒有空間了,然後客戶分別數據庫想刪除日記(聽說200G的日記=.=),然後顯示分別失足,然則刷新後數據庫卻曾經分別,刪除日記後,數據庫沒法附加,經由在網上查詢,總結出以下方法,幸虧有效的表都沒有破壞,只要統計表數據破壞,不外沒緊要橫豎功課會重置這些表的.
--確保企業治理器沒有翻開任何數據庫
--設置數據庫緊迫狀況
use master
go
sp_configure 'allow updates',1
go
reconfigure with override
go
--設置數據庫為緊迫形式
update sysdatabases set status=-32768 where dbid=DB_ID('Procurement')
--重建數據庫日記文件
dbcc rebuild_log('Procurement','D:\Procurement_log.ldf')
--驗證數據庫分歧性（可省略）
dbcc checkdb('Procurement')
--設置數據庫為正常狀況
sp_dboption 'Procurement','dbo use only','false'
--最初一步，我們要將步調E中設置的“許可對體系目次直接修正”一項恢復
sp_configure 'allow updates',0
go
reconfigure with override
go
如今你的數據庫就許可銜接了,如今可以檢查一下每一個表的數據能否有成績,假如有成績,只能找專業的數據答復了。
