redis需特別注意的場景
1、 時間複雜度大o(big onotation)
當問題的規模，不斷變化，執行時間也會不斷變化。這就是時間複雜度大o的概念。對於redis來說，時間複雜度可以用來描述在某個場景的資料規模下，乙個命令會有多快。
redis文件會告訴我們每乙個命令的時間複雜度，它也會告訴我們影響命令效能的關鍵因素。
我們這裡舉幾個例子：
o(1) 可以表示使用時間最短的。例如，sismember，redis還有好多命令也都是o(1).
o(log(n)) 使用時間僅次於o(1)。例如，zadd。
o(n)屬於線性的，在關係型資料庫中，查詢沒有索引的列，就是o(n)的操作。redis中的ltrim也是o(n)的操作。不過，這個n不是列表的個數，而是要刪除的元素個數。
o(log(n)+m) 比線性使用時間還長。例如，zremrangebyscore，刪除有序集合中排序在某個區間段上的資料。n是集合的元素個數，m是要刪除的元素個數。
o(n+m*log(m))，是redis中時間複雜度最高的。例如，sort
2、 偽多鍵查詢(pseudomulti key queries)
有乙個很常見的情況，你要通過多個key，查詢同乙個value。比如，你既想通過email 查詢使用者資料，也想通過id查詢使用者資料。乙個非常可怕的解決辦法，就是再複雜乙份value，類似下面的。
set users:[email protected] ''
set users:123 ''
乙個比較好的解決辦法，應該使用redis的hash。
set users:123 ''
hset users:id:email [email protected] 123
get users:123
如果想通過email找到使用者，需要執行兩個命令：
hget users:id:email [email protected]
get users:#
redis還支援管道。通常情況下，客戶端每個請求命令發出後，會阻塞，等待redis服務處理，redis處理完後請求命令後會將結構通過響應報文返回給client。利用管道模式，我們可以從客戶端發出多條命令，不需要等待單條命令的返回，redis服務端會將多條命令的處理結果打包一起返回給客戶端。這減少網路開銷，效能得到顯著提公升。 利用pipeline打包命令傳送，redis必須在處理完所有命令前線快取起所有命令的處理結果。打包的命令越多，快取消耗記憶體也越多。所以並不是打包的命令越多越好。具體多少合適需要根據情況測試。下面是jedis客戶端利用pipeline的一段**。
public void usepipeline(int count)』mysql特別點 Mysql 特別注意點！
初始環境 create table product id int unsigned not null auto increment,amount int unsigned default null primary key id engine innodb charset utf8 insert in...
元件使用特別注意 CoInitialize
話說coinitialize與couninitialize是夫妻 使用如下 coinitialize null 元件使用 部分 couninitialize 但是，特別注意 所有的元件 使用都得在其中，我們在函式中獲取某個元件的指標作為返回值時，特別出錯。iwebbrowser2 create re...
gitignore特別注意事項！！！
此處只說注意事項，踩過的坑，拒絕回踩 gitignore.txt檔案中，不支援級聯目錄的 號匹配，比如企圖過濾掉target和user目錄下所有檔案，因此這樣寫 錯誤寫法演示 target user 以上寫法中，會被單獨解釋為所有檔案，因此再提交時，會返回nothing to commit的錯 此錯...