在群裡小夥伴提出的乙個問題，感覺很有意思，所以專門分享一下。
在運維資料庫的時候，有時候會遇到磁碟寫入非常頻繁的情況。磁碟活動時間100%，佇列長度高等。如下圖：
此時，我們經常會去做的一件事情是，開啟profier 然後檢視write數字高的語句，找出是什麼語句造成的寫入壓力。
關於這個列，微軟的說明如下：代表寫入物理磁碟的次數
微軟在官網文件：
資料修改的過程
當客戶端發出如下請求時：update test set id=10 where id=1 ，資料庫內部修改過程如下：
1 .修改記憶體中，也就是buffer pool裡面的資料頁.
2.把日誌寫入ldf日誌檔案
此時 事務就可以提交了。對前面應用來講。這個update操作已經完成。
3.後台程序進行checkpoint 或者 lzay writer 的時候，才會吧記憶體中的髒頁重新整理到mdf磁碟檔案
不過對於批量寫入比如bulk insert and select into.，有乙個 eager writer。頁面可能會馬上被寫入磁碟。
select '更新前', num_of_writes, num_of_bytes_written
--更新後
select *
from sys.dm_os_buffer_descriptors
where database_id = db_id()
and is_modified = 1
select '更新後', num_of_writes, num_of_bytes_written
從圖中，可以看到，髒頁增加了，但是 資料檔案的寫入次數並沒有增加。
--checkpoint以後
checkpoint
select *
from sys.dm_os_buffer_descriptors
where database_id = db_id()
and is_modified = 1
select 'checkpoint後', num_of_writes, num_of_bytes_written
checkpoint以後髒頁沒有了，寫入磁碟次數從77變成了84
從上面測試可以看出，profiler裡面的writer 字段 和官方的描述有出入。並不能代表實際的磁碟寫入.所以如果磁碟有壓力還需要從其他的是方法去排查。
關於python類的誤區
1 關於類裡面的self定義，同理，self是可以被替換為其他字元的，只是標記的一種 class test def prt self print self print self.class t test t.prt main test instance at 0x100771878 main tes...
關於參加ACM的幾個誤區
關於參加 acm的幾個誤區 一 不要做了幾百個題目就把自己當牛人，這只是成為牛人的必要條件而不是充分條件 二 不要才做了幾個水題就學大牛說 做題多了沒用 至少先ac 500題再來思考這個問題 正如不要人云亦云什麼 錢多了沒用 一樣，這都是有錢人的感慨 三 不要在多次失敗後總找藉口說 發揮不好 或者 ...
關於js閉包的誤區
一直以為js的閉包只是內部函式儲存了乙份外部函式的變數值副本，但是以下 打破了我的認識 function createfunctions return result var funcs createfunctions for var i 0 i 10 i 執行結果是10個10 而不是0 9 看了js...