避免大sql
處理方法：
1、用BACKUP LOG database WITH NO_LOG清除日誌
把資料庫屬性中的故障還原模型改為「簡單」可以大大減慢日誌增長的速度。
用BACKUP LOG database WITH NO_LOG命名後，會截斷不活動日誌，不減小物理日誌文件的大小，但邏輯日誌會減小，收縮資料庫後會把不活動虛擬日誌刪除來釋放空間，不會損壞數據。
如果日誌被截斷並收縮資料庫後，就不能直接用最近的一個全庫備份做時間點還原，建議立即備份資料庫，以防萬一。
2、sql server運行中，刪除主資料庫事務日誌文件，步驟如下：
(1)、分離資料庫管理器－資料庫－右擊要刪除日誌的資料庫－所有任務－分離資料庫
(2)、然後刪除日誌文件
(3)、然後再附加資料庫
企業管理器－資料庫－右擊資料庫－所有任務－附加資料庫時只附加mdf.
3、壓縮SQL資料庫及日誌的詳細方法
可以在資料庫屬性選項中選擇「Auto shrink」選項，讓系統自動壓縮資料庫，也可以用人工的方法來壓縮。
2. sql注入如何防止
1、使用參數化篩選語句
為了防止SQL注入，用戶輸入不能直接嵌入到SQL語句中。相反，用戶輸入必須被過濾或參數化。參數語句使用參數，而不是將用戶輸入嵌入語句中。在大多數情況下，SQL語句是正確的。然後，用戶輸入僅限於一個參數。
一般來說，有兩種方法可以確保應用程序不易受到SQL注入攻擊。一種是使用代碼審查，另一種是強制使用參數化語句。強制使用參數化語句意味著在運行時將拒絕嵌入用戶輸入中的SQL語句。但是，目前對此功能的支持不多。
2、避免使用解釋程序，這是黑 客用來執行非法命令的手段。
3、防止SQL注入，但也避免一些詳細的錯誤消息，因為黑客可以使用這些消息。標準的輸入驗證機制用於驗證所有輸入數據的長度、類型、語句和企業規則。
4、使用漏洞掃描工具。
但是，防範SQL注入攻擊是不夠的。攻擊者現在自動搜索和攻擊目標。它的技術甚至可以很容易地應用於其他Web體系結構中的漏洞。企業應該投資於專業的漏洞掃描工具，如著名的Accunetix網路漏洞掃描程序。完美的漏洞掃描器不同於網路掃描器，它專門在網站上查找SQL注入漏洞。最新的漏洞掃描程序可以找到最新發現的漏洞。
5、最後，做好代碼審計和安全測試。
3. 如何避免sql事務日誌增長過快
要防止事務日誌文件異常增長，建議使用以下方法之一： 將事務日誌文件的大小設置為一個較大值，以避免事務日誌文件自動擴展。 充分評估最佳內存大小後，使用內存單位而不是百分比來配置事務日誌文件的自動擴展。有關配置自動增長選項時需要考慮的問題的其他信息，請單擊下面的文章編號，以查看 Microsoft 知識庫中相應的文章： 315512 SQL Server 中自動增長和自動收縮配置注意事項 更改恢復模式。如果發生災難或數據損壞，您必須恢復資料庫，以維護資料庫數據的一致性和事務的完整性。根據數據在資料庫中的重要程度，您可以選擇以下恢復模式之一，以便確定如何備份數據以及數據丟失可能給您帶來的風險： 簡單恢復模式 (SIMPLE) 完整恢復模式 (FULL) 大容量日誌記錄恢復模式 (BULK-LOGGED)使用簡單恢復模式，您可以將資料庫恢復到最近的資料庫備份。使用完整恢復模式或大容量日誌記錄恢復模式，您可以通過使用事務日誌文件備份來還原資料庫，這樣可以將資料庫恢復到故障發生時的故障點。默認情況下，在 SQL Server 2000 和 SQL Server 2005 中，SQL Server 資料庫的恢復模式被設置為完整恢復模式。在完整恢復模式中，會定期備份事務日誌，從而防止事務日誌文件增長得過大，以致與資料庫大小相比嚴重失衡。相比之下，如果不執行事務日誌的定期備份，事務日誌文件會不斷增長，直至充滿整個磁碟，而且您可能無法對 SQL Server 資料庫執行任何數據修改操作。如果您不希望在災難恢復操作過程中使用事務日誌文件，則可以從完整恢復模式更改為簡單恢復模式。 定期備份事務日誌文件，刪除事務日誌中非活動的事務。 將事務設計為小型事務。 確保沒有任何未遂事務繼續無限期地運行。 將「更新統計」選項安排為每天運行。 要對索引進行碎片整理以改善生產環境中的工作負荷性能，請使用 DBCC INDEXDEFRAG Transact-SQL 語句而不是 DBCC DBREINDEX Transact-SQL 語句。如果運行 DBCC DBREINDEX 語句，當 SQL Server 資料庫處於完整恢復模式時，事務日誌可能會大大擴展。此外，DBCC INDEXDEGRAG 語句不像 DBCC DBREINDEX 語句那樣長時間持有鎖。有關對 SQL Server 2000 中的索引進行碎片整理的其他信息，請參見以下 Microsoft 網站： http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/ss2kidbp.mspx如果您必須運行 DBCC DBREINDEX 語句（因為這是一個作業，是資料庫維護計劃的一部分），則必須將該作業分解為多個作業。此外，在執行這些作業的間歇，還必須經常備份事務日誌。
4. sql資料庫怎麼避免日誌增長過快
SQL server控制日誌增長採取措施：
1.清空日誌
DUMP TRANSACTION 庫名 WITH NO_LOG
2.收縮資料庫文件(如果不壓縮,資料庫的文件不會減小)
先提供一種復雜的方法壓縮日誌及資料庫文件如下：
1.清空日誌
DUMP TRANSACTION 庫名 WITH NO_LOG
2.截斷事務日誌：
BACKUP LOG 資料庫名 WITH NO_LOG
3.收縮資料庫文件(如果不壓縮,資料庫的文件不會減小
企業管理器--右鍵你要壓縮的資料庫--所有任務--收縮資料庫--收縮文件
--選擇日誌文件--在收縮方式里選擇收縮至天天上網M,這里會給出一個允許收縮到的最小M數,直接輸入這個數,確定就可以了
--選擇數據文件--在收縮方式里選擇收縮至天天上網M,這里會給出一個允許收縮到的最小M數,直接輸入這個數,確定就可以了
也可以用SQL語句來完成
--收縮資料庫
DBCC SHRINKDATABASE(客戶資料)
--收縮指定數據文件,1是文件號,可以通過這個語句查詢到:select * from sysfiles
DBCC SHRINKFILE(1)
4.為了最大化的縮小日誌文件(如果是sql 7.0,這步只能在查詢分析器中進行)
a.分離資料庫:
企業管理器--伺服器--資料庫--右鍵--分離資料庫
b.在我的電腦中刪除LOG文件
c.附加資料庫:
企業管理器--伺服器--資料庫--右鍵--附加資料庫
此法將生成新的LOG，大小隻有500多K
或用代碼：
下面的示例分離 pubs，然後將 pubs 中的一個文件附加到當前伺服器。
a.分離
E X E C sp_detach_db @dbname = 』pubs『
b.刪除日誌文件
c.再附加
E X E C sp_attach_single_file_db @dbname = 『pubs』,
@physname = 』c:\Program Files\Microsoft SQL Server\MSSQL\Data\pubs.mdf『
5.為了以後能自動收縮,做如下設置:
企業管理器--伺服器--右鍵資料庫--屬性--選項--選擇"自動收縮"
--SQL語句設置方式:
E X E C sp_dboption 』資料庫名『, 』autoshrink『, 』TRUE『
6.如果想以後不讓它日誌增長得太大
企業管理器--伺服器--右鍵資料庫--屬性--事務日誌
--將文件增長限制為xM(x是你允許的最大數據文件大小)
--SQL語句的設置方式:
alter database 資料庫名 modify file(name=邏輯文件名,maxsize=20)
5. MySQL高性能SQL注意事項簡述
資料庫作為應用開發中必不缺少的基礎設施，其性能直接影響應用的整體運行速度。MySQL是目前最廣泛使用的關系型資料庫之一，對於開發人員寫出性能良好的SQL是必備的基本技能之一。下面簡單描述下編寫SQL的注意事項。
編寫高質量的SQL需要從以下幾個方面注意，基本原則、表欄位注意事項、索引使用注意事項、SQL注意事項。
基本原則
一、盡量不要在資料庫里做運算。如果遇到運算盡可能在應用程序層進行計算。
二、控制資料庫表數量、控制單表數據量、控製表的欄位數。建議單庫不要超過四百張表，建議單表欄位不要超過五十個，建議單表的數據量不要超過一千萬。
三、不要編寫大SQL、不要使用大事務。SQL盡量寫的簡單點拒絕編寫大SQL，可以將大SQL拆分成多個小SQL，在應用層聚合。大事務拆分成多個小事務，快速提交。
表欄位注意事項
一、選擇合適數值欄位類型。能用小欄位類型的就用小欄位類型，如tinyint就比int(1)在表示小數據時合適。
二、能用數字表示就不要用字元。如可以用無符號INT存儲IP而不是字元串表示。
三、避免使用NULL欄位。原因NULL欄位查詢優化難，含NULL復合索引失效。
四、少用或拆分TEXT/BLOB欄位。欄位太大需要更多的空間，性能低下，如需使用拆分到單獨表。
五、不要在表欄位中存儲圖片。
索引使用注意事項
一、合理添加索引。索引添加太多會影響更新速度。能夠使用復合索引的避免加多個單獨索引。
二、字元欄位建立前綴索引。
三、不在索引列做運算。索引列做運算會導致索引失效。
四、盡量不使用外建。
SQL類注意事項
一、 SQL語句盡可能簡單。大SQL拆分成多個小SQL。
二、事務編寫盡量短小。事務即開即用用完立即關閉。
三、盡量不要使用select *。只取需要的列。
四、改寫OR為IN或者改寫為UNION操作。OR在數據量大的時候性能低於IN。
五、避免NOT、!=、>、NOT IN、NOT EXISTS、NOT LIKE等查詢。
六、避免%前綴模糊查詢。
七、能用UNION ALL不要用UNION。
八、GROUP BY中去除排序。自帶排序。
九、同類型的欄位做比較。字元類和字元類比較，數值類和數值類比較，不要混在一起比較。
十、盡量單表查詢，盡量不要多表關聯查詢。多表關聯查詢可以拆分成單表查詢在應用程序中聚合數據。
十一、復合索引的多列注意最左原則。
上述注意事項能避免很多性能低下的SQL，希望在開發過程中能引起注意。
6. SQL資料庫文件太大怎麼處理
如果是MSSQL在任務里選資料庫收縮，可以縮小很多。
不然只能把數據導出來減小資料庫了。
7. 如何實現php的安全最大化怎樣避免sql注入漏洞和xss跨站腳本攻擊漏洞
使用php安全模式
伺服器要做好管理，賬號許可權是否合理。
假定所有用戶的輸入都是「惡意」的，防止XSS攻擊，譬如：對用戶的輸入輸出做好必要的過濾
防止CSRF，表單設置隱藏域，post一個隨機字元串到後台，可以有效防止跨站請求偽造。
文件上傳，檢查是否做好效驗，要注意上傳文件存儲目錄許可權。
防禦SQL注入。
避免SQL注入漏洞
1.使用預編譯語句
2.使用安全的存儲過程
3.檢查輸入數據的數據類型
4.從資料庫自身的角度考慮，應該使用最小許可權原則，不可使用root或dbowner的身份連接資料庫。若多個應用使用同一個資料庫，也應該為資料庫分配不同的賬戶。web應用使用的資料庫賬戶，不應該有創建自定義函數，操作本地文件的許可權。
避免XSS跨站腳本攻擊
1.假定所有用戶輸入都是「邪惡」的
2.考慮周全的正則表達式
3.為cookie設置HttpOnly,防止cookie劫持
4.外部js不一定可靠
5.出去不必要的HTML注釋
6. 針對非法的HTML代碼包括單雙引號等，使用htmlspecialchars()函數。
8. 如何避免代碼中出現sql注入
普通用戶與系統管理員用戶的許可權要有嚴格的區分。
如果一個普通用戶在使用查詢語句中嵌入另一個Drop Table語句，那麼是否允許執行呢?由於Drop語句關繫到資料庫的基本對象，故要操作這個語句用戶必須有相關的許可權。在許可權設計中，對於終端用戶，即應用軟體的使用者，沒有必要給他們資料庫對象的建立、刪除等許可權。那麼即使在他們使用SQL語句中帶有嵌入式的惡意代碼，由於其用戶許可權的限制，這些代碼也將無法被執行。故應用程序在設計的時候，
強迫使用參數化語句。
如果在編寫SQL語句的時候，用戶輸入的變數不是直接嵌入到SQL語句。而是通過參數來傳遞這個變數的話，那麼就可以有效的防治SQL注入式攻擊。也就是說，用戶的輸入絕對不能夠直接被嵌入到SQL語句中。與此相反，用戶的輸入的內容必須進行過濾，或者使用參數化的語句來傳遞用戶輸入的變數。參數化的語句使用參數而不是將用戶輸入變數嵌入到SQL語句中。採用這種措施，可以杜絕大部分的SQL注入式攻擊。不過可惜的是，現在支持參數化語句的資料庫引擎並不多。不過資料庫工程師在開發產品的時候要盡量採用參數化語句。
多多使用SQL Server資料庫自帶的安全參數。
為了減少注入式攻擊對於SQL Server資料庫的不良影響，在SQLServer資料庫專門設計了相對安全的SQL參數。在資料庫設計過程中，工程師要盡量採用這些參數來杜絕惡意的SQL注入式攻擊。
如在SQL Server資料庫中提供了Parameters集合。這個集合提供了類型檢查和長度驗證的功能。如果管理員採用了Parameters這個集合的話，則用戶輸入的內容將被視為字元值而不是可執行代碼。即使用戶輸入的內容中含有可執行代碼，則資料庫也會過濾掉。因為此時資料庫只把它當作普通的字元來處理。使用Parameters集合的另外一個優點是可以強制執行類型和長度檢查，范圍以外的值將觸發異常。如果用戶輸入的值不符合指定的類型與長度約束，就會發生異常，並報告給管理員。如上面這個案例中，如果員工編號定義的數據類型為字元串型，長度為10個字元。而用戶輸入的內容雖然也是字元類型的數據，但是其長度達到了20個字元。則此時就會引發異常，因為用戶輸入的內容長度超過了資料庫欄位長度的限制。
加強對用戶輸入的驗證。
總體來說，防治SQL注入式攻擊可以採用兩種方法，一是加強對用戶輸入內容的檢查與驗證;二是強迫使用參數化語句來傳遞用戶輸入的內容。在SQLServer資料庫中，有比較多的用戶輸入內容驗證工具，可以幫助管理員來對付SQL注入式攻擊。測試字元串變數的內容，只接受所需的值。拒絕包含二進制數據、轉義序列和注釋字元的輸入內容。這有助於防止腳本注入，防止某些緩沖區溢出攻擊。測試用戶輸入內容的大小和數據類型，強制執行適當的限制與轉換。這即有助於防止有意造成的緩沖區溢出，對於防治注入式攻擊有比較明顯的效果。
如可以使用存儲過程來驗證用戶的輸入。利用存儲過程可以實現對用戶輸入變數的過濾，如拒絕一些特殊的符號。如以上那個惡意代碼中，只要存儲過程把那個分號過濾掉，那麼這個惡意代碼也就沒有用武之地了。在執行SQL語句之前，可以通過資料庫的存儲過程，來拒絕接納一些特殊的符號。在不影響資料庫應用的前提下，應該讓資料庫拒絕包含以下字元的輸入。如分號分隔符，它是SQL注入式攻擊的主要幫凶。如注釋分隔符。注釋只有在數據設計的時候用的到。一般用戶的查詢語句中沒有必要注釋的內容，故可以直接把他拒絕掉，通常情況下這么做不會發生意外損失。把以上這些特殊符號拒絕掉，那麼即使在SQL語句中嵌入了惡意代碼，他們也將毫無作為。
多層環境如何防治SQL注入式攻擊?
在多層應用環境中，用戶輸入的所有數據都應該在驗證之後才能被允許進入到可信區域。未通過驗證過程的數據應被資料庫拒絕，並向上一層返回一個錯誤信息。實現多層驗證。對無目的的惡意用戶採取的預防措施，對堅定的攻擊者可能無效。更好的做法是在用戶界面和所有跨信任邊界的後續點上驗證輸入。如在客戶端應用程序中驗證數據可以防止簡單的腳本注入。但是，如果下一層認為其輸入已通過驗證，則任何可以繞過客戶端的惡意用戶就可以不受限制地訪問系統。故對於多層應用環境，在防止注入式攻擊的時候，需要各層一起努力，在客戶端與資料庫端都要採用相應的措施來防治SQL語句的注入式攻擊。