『壹』 誰能通俗易懂的說下sql注入的危害和最簡單的解決辦法(php)
不是行不通了，這種萬能密碼是需要一定條件的
sql注入危害可大可小
大了說，可以進一步控制的你web伺服器，盜取帳號密碼，篡改你的web頁面。
小了說，只能瀏覽一些已知的數據（比如刪查改分別使用不同的用戶可以有一定防範效果）
解決方法的話，建議使用成熟的資料庫框架或者通過格式化之後在帶入資料庫執行。
『貳』 SQL注入的特點與危害分別有哪些
1、廣泛性：任何一個基於SQL語言的資料庫都可能被攻擊，很多開發人員在編寫Web應用程序時未對從輸入參數、Web表單、Cookie等接收到的值進行規范性驗證和檢測，通常會出現SQL注入漏洞。
2、隱蔽性：SQL注入語句一般都嵌入在普通的HTPP請求中，很難與正常語句區分開，所以當前許多防火牆都無法識別予以警告，而且SQL注入變種極多，攻擊者可以調整攻擊的參數，所以使用傳統的方法防禦SQL注入效果非常不理想。
3、危害大：攻擊者可以通過SQL注入獲取到伺服器的庫名、表名、欄位名，從而獲取到整個伺服器中的數據，對網站用戶的數據安全有極大的威脅。攻擊者也可以通過獲取到的數據，得到後台管理員的密碼，然後對網頁頁面進行惡意篡改。這樣不僅對資料庫信息安全造成嚴重威脅，對整個資料庫系統安全也有很大的影響。
4、操作方便：互聯網上有很多SQL注入工具，簡單易學、攻擊過程簡單，不需要專業的知識也可以自如運用。
『叄』 sql中的冗餘會導致什麼問題急
冗餘有好處， 也有壞處。
是一個要把握好一個度的問題。
冗餘的好處是， 查詢的時候， 可以少關聯一點表。
冗餘的壞處是， 多佔用一些磁碟空間， 更新的時候， 要更新多一點表。
例如下面這樣的體系結構：
學生表（學號，姓名）
課程表（課程號，課程名）
成績表（學號，課程號，成績）
上面這種情況， 成績表中沒有冗餘的列，那麼要查詢 姓名，課程名，成績的情況下。
需要3個表都關聯了， 進行查詢。
下面是有冗餘的課程表
成績表（學號，姓名，課程號，課程名，成績）
上面這種情況， 成績表中包含了冗餘的列，那麼要查詢 姓名，課程名，成績的情況下。
只需要查詢一個表就可以了。
但是潛在的問題： 例如 學號為 008 的學生改名字了。
在成績表中沒有冗餘的列的情況下， 簡單 學生表， 修改 學號為 008 的學生的姓名即可。
而在成績表中有冗餘的列的情況下， 需要修復 學生表 與 成績表 上面的 學號為 008 的學生的姓名。
上面只是簡單的例子。
一般來說，徹底一點冗餘也沒有， 感覺上是很好， 但是如果遇到數據量很大，表關聯又很多的情況下， 查詢速度就會慢一些。
但是你要冗餘得太厲害了， 那麼更新數據的時候， 也是要命的。
『肆』 sql多表查詢及查詢語句太長問題（aspaccess）
你這么寫 sql很不科學的，建議這么寫，
使用連接查詢，表的別名
如：
select * from table1 t1
inner join table2 t2 on t1.zian1 = t2.zian1
inner join table3 t3 on t2.zian1 = t3.zian1
where 其他條件
『伍』 SQL資料庫和甲骨文資料庫的好處和壞處求解答！
MsSqlserver優點：
1.真正的客戶機/伺服器體系結構
2.圖形化的用戶界面，使系統管理和資料庫管理更加直觀、簡單
3.豐富的編程介面工具，為用戶進行程序設計提供了更大的選擇餘地
4.與WinNT完全集成，利用了NT的許多功能，如發送和接受消息，管理登錄安全性等，SQL Server也可以很好地與Microsoft BackOffice產品集成。
5.有很好的伸縮性，可以跨平台使用。
6.提供數據倉庫功能，這個功能只在Oracle和其他昂貴的DBMS中才有。
Oracle優點：
1.Oracle的穩定性要比Sql server好。
2.Oracle在導數據工具sqlload.exe功能比Sqlserver的Bcp功能強大,Oracle可以按照條件把文本文件數據導入.
3.Oracle的安全機制比Sql server好。
4.Sql server的易用性和友好性方面要比Oracle好。
5.在處理大數據方面Oracle會更穩定一些。
6.Sql Server在數據導出方面功能更強一些。
7.處理速度方面比Oracle快一些，和兩者的協議有關.
Oracle缺點： 價格昂貴.
以下是搜集與網路中常用資料庫的總結，希望大家補充~！
SqlServer：只支持微軟平台，數據量不及上兩者，可用性最好，但是性能不及上兩者，適用於中型、小型企業及商業應用。
1. SQL SERVER 用於中小型資料庫,ORACLE 用於大型資料庫.
2. SQL SERVER 只能在Windows下跑,Oracle是跨平台的.
3. SQL SERVER 很平民,輕巧,Oracle很貴族,安全穩定.
1、主要在處理數據量的大小方面：sql小數據量速度快、方便。oracle慢；但海量數據處理，就非oracle莫數了。
2、操作方便性：sql操作方便簡單，易上手。oracle操作麻煩、不易上手。
3、安全性：sql安全性很差（最大缺點）。oracle安全性很好。
4、移植性：sql只能在windows系統和NT系統下運行。oracle理論上可以運行在任何的系統中。
Oracle是(甲骨文)公司的數據產品。Oracle的產品可運行於很寬范圍的硬體與操作系統平台上。可以安裝在70種以上不同的大、中、小型機上；可在VMS、DOS、UNIX、WINDOWS等多種操作系統下工作。ORACLE產品主要包括資料庫伺服器、開發工具和連接產品三類。操作要比MSSQL Server復雜，同時提供GUI和命令行，在windowsNT和unix下操作相同。獲得最高認證級別的ISO標准認證。
SQL Server 是 Microsoft(微軟) 的數據產品，它的易用性強。有友好的用戶界面。適用於C/S結構，只支持windows客戶，可以用ADO,DAO,OLEDB,ODBC連接.但只能在windows 上運行，沒有絲毫的開放性，而且windows平台的可靠性，安全性和伸縮性是非常有限的。多用戶時性能不佳。適用於中端市場,價格也比較適中.但在安全性方面沒受到任何安全認證.
『陸』 sql語言 缺點
你可以先看一下sql
server的書，這樣的書比較多。隨便翻一本基礎的就可以，先選擇性看select
delete\update\等這些常用的語句，熟悉以後再看觸發器、存儲過程、自定義函數、游標等！
『柒』 SQL語句執行很慢，怎麼回事
1. 執行計劃中明明有使用到索引，為什麼執行還是這么慢？
2. 執行計劃中顯示掃描行數為 644，為什麼 slow log 中顯示 100 多萬行？
a. 我們先看執行計劃，選擇的索引 「INDX_BIOM_ELOCK_TASK3(TASK_ID)」。結合 sql 來看，因為有 "ORDER BY TASK_ID DESC" 子句，排序通常很慢，如果使用了文件排序性能會更差，優化器選擇這個索引避免了排序。
那為什麼不選 possible_keys:INDX_BIOM_ELOCK_TASK 呢？原因也很簡單，TASK_DATE 欄位區分度太低了，走這個索引需要掃描的行數很大，而且還要進行額外的排序，優化器綜合判斷代價更大，所以就不選這個索引了。不過如果我們強制選擇這個索引（用 force index 語法），會看到 SQL 執行速度更快少於 10s，那是因為優化器基於代價的原則並不等價於執行速度的快慢；
b. 再看執行計劃中的 type:index，"index" 代表 「全索引掃描」，其實和全表掃描差不多，只是掃描的時候是按照索引次序進行而不是行，主要優點就是避免了排序，但是開銷仍然非常大。
Extra:Using where 也意味著掃描完索引後還需要回表進行篩選。一般來說，得保證 type 至少達到 range 級別，最好能達到 ref。
在第 2 點中提到的「慢日誌記錄Rows_examined: 1161559，看起來是全表掃描」，這里更正為「全索引掃描」，掃描行數確實等於表的行數；
c. 關於執行計劃中：「rows：644」，其實這個只是估算值，並不準確，我們分析慢 SQL 時判斷准確的掃描行數應該以 slow log 中的 Rows_examined 為准。
4. 優化建議：添加組合索引 IDX_REL_DEVID_TASK_ID(REL_DEVID,TASK_ID)
優化過程：
TASK_DATE 欄位存在索引，但是選擇度很低，優化器不會走這個索引，建議後續可以刪除這個索引：
select count(*),count(distinct TASK_DATE) from T_BIOMA_ELOCK_TASK;+------------+---------------------------+| count(*) | count(distinct TASK_DATE) |+------------+---------------------------+| 1161559 | 223 |+------------+---------------------------+
在這個 sql 中 REL_DEVID 欄位從命名上看選擇度較高，通過下面 sql 來檢驗確實如此：
select count(*),count(distinct REL_DEVID) from T_BIOMA_ELOCK_TASK;+----------+---------------------------+| count(*) | count(distinct REL_DEVID) |+----------+---------------------------+| 1161559 | 62235 |+----------+---------------------------+
由於有排序，所以得把 task_id 也加入到新建的索引中，REL_DEVID,task_id 組合選擇度 100%：
select count(*),count(distinct REL_DEVID,task_id) from T_BIOMA_ELOCK_TASK;+----------+-----------------------------------+| count(*) | count(distinct REL_DEVID,task_id) |+----------+-----------------------------------+| 1161559 | 1161559 |+----------+-----------------------------------+
在測試環境添加 REL_DEVID，TASK_ID 組合索引，測試 sql 性能：alter table T_BIOMA_ELOCK_TASK add index idx_REL_DEVID_TASK_ID(REL_DEVID,TASK_ID);
添加索引後執行計劃：
這里還要注意一點「隱式轉換」：REL_DEVID 欄位數據類型為 varchar，需要在 sql 中加引號：AND T.REL_DEVID = 000000025xxx >> AND T.REL_DEVID = '000000025xxx'
執行時間從 10s+ 降到 毫秒級別：
1 row in set (0.00 sec)
結論
一個典型的 order by 查詢的優化，添加更合適的索引可以避免性能問題：執行計劃使用索引並不意味著就能執行快。
『捌』 一大串拆分的SQL語句對資料庫是否有影響
對資料庫本身是沒有什麼影響的！
所有的SQL語句都是在緩存中解析執行，並將結果存放在緩存中的。
『玖』 sql語句太長有什麼壞處嗎
不能說壞處，有很多資料庫本身的結構、演算法就比較復雜，語句長是很正常的。只是同等效果的語句，盡量選擇精簡的。還有就是書寫的格式，很重要，盡量多使用分行書寫。語句的效率主要體現：
1、可讀性，也就是再次查看、修改sql語句時，容易閱讀。
2、執行效率，如一些重復分組、重復的計算，造成的語句執行速度緩慢。