『壹』 如何修改資料庫所有表varchar至nvarchar而不需要刪除索引
altertableAmodifym(number(10));裡面的10是我自己寫的，就是你原來varchar2的長度，你在實際執行時修改一下。
『貳』 db2查詢條件(varchar類型)不帶引號與索引有沒有關系
跟索引沒有關系。
是sql語句、或者表結構、或者記錄值的問題。
post你的實例、證據上來，別空說。
『叄』 varchar(500)換成varchar(50)有什麼影響
一般主鍵或者索引都有一個最大長度，對於sql server 2005來說，最大的長度是900位元組，如果欄位類型是varchar(500)，那麼可以放500個字元，如果是gbk的字元，那麼就要佔用1000個位元組，如果將這個欄位設置為主鍵，就超過了900位元組的長度。
你講varcahr(500)換成了varchar(50)後，此欄位最大的佔用位元組數是100，小於900，所以就可以設置為主鍵了。
至於影響，就是如果你要在A1欄位中存超過50個字元，就會被截斷。如果你A1欄位中存的字元不會超過50個字元，那麼沒有任何影響。
『肆』 mysql怎麼添加索引sql語句
工具：mysql資料庫創建一個user的表裡邊的欄位
1.普通索引 添加INDEX
ALTER TABLE `table_name` ADD INDEX index_name ( `column` )
下面演示下給user表的name欄位添加一個索引
2.主鍵索引 添加PRIMARY KEY
ALTER TABLE `table_name` ADD PRIMARY KEY ( `column` )
3.唯一索引 添加UNIQUE
ALTER TABLE `table_name` ADD UNIQUE ( `column` )
4.全文索引 添加FULLTEXT
ALTER TABLE `table_name` ADD FULLTEXT ( `column`)
5.如何添加多列索引
ALTER TABLE `table_name` ADD INDEX index_name ( `column1`, `column2`, `column3` )
『伍』 mysql varchar索引和int索引性能哪個好
性能相當，mysql中區別性能的是採用哪種索引方式，而不是索引的數據類型。
MySQL的btree索引和hash索引的區別
hash 索引結構的特殊性，其檢索效率非常高，索引的檢索可以一次定位，不像btree(B-Tree)索引需要從根節點到枝節點，最後才能訪問到頁節點這樣多次的IO訪問，所以 hash 索引的查詢效率要遠高於 btree(B-Tree) 索引。
雖然 hash 索引效率高，但是 hash 索引本身由於其特殊性也帶來了很多限制和弊端，主要有以下這些。
（1）hash 索引僅僅能滿足=，<=>，IN，IS NULL或者IS NOT NULL查詢，不能使用范圍查詢。
由於 hash 索引比較的是進行 hash 運算之後的 hash 值，所以它只能用於等值的過濾，不能用於基於范圍的過濾，因為經過相應的 hash 演算法處理之後的 hash 值的大小關系，並不能保證和hash運算前完全一樣。
（2）hash 索引無法被用來避免數據的排序操作。
由於 hash 索引中存放的是經過 hash 計算之後的 hash 值，而且hash值的大小關系並不一定和 hash 運算前的鍵值完全一樣，所以資料庫無法利用索引的數據來避免任何排序運算；
（3）hash 索引不能利用部分索引鍵查詢。
對於組合索引，hash 索引在計算 hash 值的時候是組合索引鍵合並後再一起計算 hash 值，而不是單獨計算 hash 值，所以通過組合索引的前面一個或幾個索引鍵進行查詢的時候，hash 索引也無法被利用。
（4）hash 索引在任何時候都不能避免表掃描。
前面已經知道，hash 索引是將索引鍵通過 hash 運算之後，將 hash運算結果的 hash 值和所對應的行指針信息存放於一個 hash 表中，由於不同索引鍵存在相同 hash 值，所以即使取滿足某個 hash 鍵值的數據的記錄條數，也無法從 hash 索引中直接完成查詢，還是要通過訪問表中的實際數據進行相應的比較，並得到相應的結果。
（5）hash 索引遇到大量hash值相等的情況後性能並不一定就會比B-Tree索引高。
對於選擇性比較低的索引鍵，如果創建 hash 索引，那麼將會存在大量記錄指針信息存於同一個 hash 值相關聯。這樣要定位某一條記錄時就會非常麻煩，會浪費多次表數據的訪問，而造成整體性能低下
『陸』 SQL中 NVARCHAR 和 VARCHAR 兩者之間的優勢與劣勢！！
varchar在SQL Server中是採用單位元組來存儲數據的，nvarchar是使用Unico來存儲數據的．中文字元存儲到SQL Server中會保存為兩個位元組（一般採用Unico編碼），英文字元保存到資料庫中，如果欄位的類型為varchar，則只會佔用一個位元組，而如果欄位 的類型為nvarchar，則會佔用兩個位元組．
正常情況下，我們使用varchar也可以存儲中文字元，但是如果遇到操作系統是英文操 作系統並且對中文字體的支持不全面時, 在SQL Server存儲中文字元為varchar就會出現亂碼(顯示為??)．而且正常情況下，主機都會支持中文的環境，所以如果使用varchar來存儲數 據，在開發階段是發現不了的．多數情況下，在布署的時候也不會有問題．
但是！如果布署的主機是英文操作系統，並且不支持中文環境，那問 題就出來了．所有的varchar欄位在存儲中文的時候都會變成亂碼（顯示為??）．而且一般情況下你不會知道這是因為你採用了錯誤的數據類型來存儲所造 成的，你會試著去裝中文字體，試著去設置操作系統的語言環境．．．這些都不能解決問題，唯一能解決問題的是把資料庫欄位的類型個性為nvarchar（或 者nchar）．對項目管理比較熟悉的朋友應該都知道，到布署階段再來修改資料庫是一個很恐怖的事情．
使用nvarchar的另一個非常好處就是在判斷字元串的時候可以不需要考慮中英文兩種字元的差別．
當然，使用nvarchar存儲英文字元會增大一倍的存儲空間．但是在存儲代價已經很低廉的情況下，優先考慮兼容性會給你帶來更多好處的．
所以在Design的時候應該盡量使用nvarchar來存儲數據．只有在你確保該欄位不會保存中文的時候，才採用varchar來存儲．
1、CHAR。CHAR存儲定長數據很方便，CHAR欄位上的索引效率級高，比如定義char(10)，那麼不論你存儲的數據是否達到了10個位元組，都要佔去10個位元組的空間。
2、VARCHAR。存儲變長數據，但存儲效率沒有CHAR高。如果一個欄位可能的值是不固定長度的，我們只知道它不可能超過10個字元，把它定義為 VARCHAR(10)是最合算的。VARCHAR類型的實際長度是它的值的實際長度+1。為什麼「+1」呢？這一個位元組用於保存實際使用了多大的長度。
從空間上考慮，用varchar合適；從效率上考慮，用char合適，關鍵是根據實際情況找到權衡點。
3、TEXT。text存儲可變長度的非Unicode數據，最大長度為2^31-1(2,147,483,647)個字元。
4、NCHAR、NVARCHAR、NTEXT。這三種從名字上看比前面三種多了個「N」。它表示存儲的是Unicode數據類型的字元。我們知道字元中，英文字元只需要一個位元組存儲就足夠了，但漢字眾多，需要兩個位元組存儲，英文與漢字同時存在時容易造成混亂，Unicode字元集就是為了解決字元集這種不兼容的問題而產生的，它所有的字元都用兩個位元組表示，即英文字元也是用兩個位元組表示。nchar、nvarchar的長度是在1到4000之間。和char、varchar比較起來，nchar、nvarchar則最多存儲4000個字元，不論是英文還是漢字；而char、varchar最多能存儲8000個英文，4000個漢字。可以看出使用nchar、nvarchar數據類型時不用擔心輸入的字元是英文還是漢字，較為方便，但在存儲英文時數量上有些損失。
所以一般來說，如果含有中文字元，用nchar/nvarchar，如果純英文和數字，用char/varchar
『柒』 mysql 資料庫里搜索商品名稱，但是name(varchar)欄位沒建立索引，用什麼方法效率最高
單獨的索引和復合索引的索引。單一索引，只包含單個列，一個表可以有多個單獨的索引，而不是索引的組合的索引。綜合指數，即包含多個列的電纜。
MySQL索引的類型包括：
（1）一般指數
這是最基本的索引，它沒有任何限制。它創造了幾種方法：
◆創建一個索引
CREATE INDEX INDEXNAME ON mytable的（用戶名（長度））;
如果CHAR，VARCHAR類型，長度可以小於的實際長度場，如果是BLOB和TEXT類型，必須指定長度，下同。
◆表結構
ALTER mytable的ADD INDEX [INDEXNAME]開（用戶名（長度））
◆當您創建一個表直接指定
CREATE TABLE mytable的（ID INT NOT NULL ，用戶名VARCHAR（16）NOT NULL，索引[INDEXNAME]（用戶名（長度）））;
刪除索引的語法：
DROP INDEX [INDEXNAME] ON mytable的;
（2）唯一索引
它類似於以前的一般指標，不同的是：索引列的值必須是唯一的，但是允許空值。如果它是一個綜合指數相結合，列值？？必須是唯一的。它創造了幾種方法：
◆創建一個索引
CREATE UNIQUE INDEX INDEXNAME ON mytable的（用戶名（長度））
◆表結構
ALTER mytable的ADD UNIQUE [INDEXNAME]開啟（用戶名（長度））
◆當您創建一個表直接指定
CREATE TABLE mytable的（ID INT NOT NULL，用戶名VARCHAR（16）NOT NULL，UNIQUE [INDEXNAME]（用戶名（長度））） ;
（3）主鍵索引
這是一個特殊的唯一索引不允許空值。一般的時候同時創建主鍵索引的表的結構：
CREATE TABLE mytable的（ID INT NOT NULL，用戶名VARCHAR（16）NOT NULL，PRIMARY KEY（ID））;
>當然，你可以使用ALTER命令。請記住：一個表只能有一個主鍵。
（4）綜合指數
對於圖像的對比度和組合索引單列索引，添加更多的欄位的表：
CREATE TABLE mytable的（ID INT NOT NULL，用戶名VARCHAR（16）NOT NULL ，城市VARCHAR（50）NOT NULL，年齡INT NOT NULL）;
為了進一步榨取MySQL的效率，就要考慮建立組合索引。是的名稱，城市，年齡建成一個索引，其中：
ALTER TABLE mytable的ADD INDEX name_city_age（名（10），城市，年齡）;
建立表時，16 usernname長度，其中10。這是因為在正常情況下不超過10名，這將加快查詢速度索引的長度，該指數將減少文件大小，提高INSERT的更新速度。
如果您創建的每個usernname一個單獨的索引，城市，年齡，所以該表有三個單獨的索引，上面的查詢和索引的組合效率會有很大的不同，遠遠超過我們的組合索引少。雖然此時有了三個索引，但MySQL只可以使用它們認為這似乎是最有效的單一指標。
建立這樣的組合索引，其實是三組相當於建立了以下綜合指數：
usernname，城市，年齡usernname，城市usernname
為什麼沒有城市，年齡該做組合索引？它是一個綜合指數，因為MySQL的結果「最左前綴」一個。這只是意味著，左側只有從一開始的組合。不僅包含了這三個疑問將在綜合指數中使用，下面的幾個SQL就會使用這個組合索引：
SELECT * FROM mytable的WHREE用戶名=「管理員」和城市=「鄭州」SELECT * FROM mytable的WHREE用戶名= 「管理員」
接下來的幾個未使用：
SELECT * FROM mytable的WHREE年齡為20及城市=「鄭州」SELECT * FROM mytable的WHREE城市=「鄭州」
（5）索引時間
在這里，我們已經學會了建立索引，那麼我們需要在什麼情況下創建索引？通常，當連接列和出現在需要建立索引，但也不完全如此，因為MySQL只<，，> =，BETWEEN，IN，LIKE，有的時候會使用索引。例如：
選擇t.Name FROM mytable的噸LEFT JOIN mytable的M於t.Name = m.username WHERE m.age = 20和m.city ='鄭州'
這時候就需要城市與年齡索引，由於userame mytable的表也出現在JOIN子句中，也有必要建立索引。
只是它需要像索引的時候一定提及。因為在一開始通配符％和_的查詢，MySQL不會使用索引。例如，下面的語句將使用索引：
SELECT * FROM mytable的其中username like'admin％'
下一句不會使用：
SELECT * FROM mytable的WHEREt名稱LIKE'％ admin的
因此，更應注意使用LIKE差異。
（6）指數
的不足之處上面是說使用索引的好處，但過量使用索引將會造成濫用。因此，該指數也有其缺點：
◆雖然索引大大提高了查詢速度，但會降低更新表，如表的INSERT，UPDATE的速度和DELETE。因為當你更新表，MySQL只保存數據，而且還節省大約索引文件。
◆建立索引會佔用磁碟空間的索引文件。通常這個問題不是太嚴重，但如果你是在一個大表創建各種復合索引，索引文件將很快擴大。
指數只是其中的一個因素，以提高效率，如果你有大量的數據的MySQL表，你需要花時間去研究建立最佳的索引，或優化查詢。
（7）使用索引
注意事項使用索引時，下面的一些技巧和注意事項：？？
◆索引不會包含NULL值的列只要列中包含 BR />有NULL值？將不會被包含在索引中，復合索引，只要有包含NULL值的列，那麼這個列是此復合索引無效。所以，我們不要讓默認欄位為NULL的資料庫設計。
就用短串聯指數指標，如果可能的話，你應該指定一個前綴長度。例如，如果一個CHAR（255）列，如果在前10或20個字元之內，多個值？是獨一無二的，那就不要索引整個列。短索引不僅可以提高查詢速度而且可以節省磁碟空間和I / O操作。
◆索引列排序
MySQL查詢只使用一個索引，因此如果where子句已在索引中使用，然後按列的順序將不會使用索引。因此，不要使用默認的資料庫排序時排序操作即可滿足要求;盡量不要包含多個排序列，如果需要的話最好創建這些列的一個綜合指數。
◆like語句
在正常情況下運行不鼓勵使用類似的操作，如果非使用不可，如何使用也是一個問題。如「％AAA％」不會使用索引而不是像「AAA％」可以使用索引。
◆不要在列選擇*從用戶那裡YEAR（錄入）<2007年
操作將在每個行上進行的，這將導致失敗而進行全表索引掃描，所以我們可以改變
選擇*從用戶那裡錄入時間<'2007-01-01';
◆不使用NOT IN和>
更多操作上的MySQL索引類型進行了介紹。
轉移： http://www.zbite.com/action-viewthread - TID-33491
『捌』 oracle中倆資料庫用戶A和B。欄位均為varchar2類型，都建有索引以下兩個查詢sql，速度為啥不一樣
差一個引號 可能導致2個查詢 完全不一樣的執行計劃， 在Oracle里差一個符號 一個空格都可能造成解析為不同的執行計劃，最後的性能天差地別， 這是很正常的。