10G的變態SQL文件，如何快速打開編輯？

• 2019 年 10 月 3 日
• 筆記

工作中，偶爾需要編輯一些大文件，比如 log 文件，後者一些變態的 SQL，此時用平常的編輯器就會顯得力不從心，要麼直接打不開，要麼打開後卡得要死。

本文就給大家推薦幾款可以操作大文件的編輯器，準備好小板凳，開始吧。

本機配置：Windows10，16G 記憶體，i5 處理器。

Notepad++

第一站，就拿我本機的記事本替代者 Notepad++ 開刀。

網上傳聞 Notepad++ 打開大文件不佳，Notepad++ 可以打開 600M 左右的文件，大於 700M 就直接無法打開了，一般 >400m 就會卡死。

那麼它的真實體驗如何呢？

於是就從伺服器上，找來了一個 2.3G 大小的文件來進行測試。

將其拖到 Notepad++ 中，直接不行：

那我們拿一個小點的，200M 多點的文件再試一下

結果呢？

大家隔著螢幕，應該無法感受我在電腦前的感受

打開用了好幾秒，打開後無法滾動，我的滑鼠都快滑爛了

好不容易能上下拉了，沒拉幾下，還卡死了！

直接程式無響應了！

Notepad++ 是很優秀，但是在打開大文件方面，簡直是一塌糊塗！

超過 100M 的文件，用 Notepad++ 打開時，請慎重！

Sublime Text

下面我們用很多人都喜歡的 Sublime Text 來試下。

首先，比 Notepad++ 好的地方是，2.3G 的文件起碼是能打開的

沒有報錯

但是，Sublime Text 開始載入文件了

我大概計了個時

載入 2.3G 的文件，一共用了 4 分多鐘

我就一直盯著載入頁面

不過總算載入完了

正當我準備滑動我的滑鼠查看文件時

再看一眼 Sublime Text 的記憶體佔用情況

看得出來，它是一次性將文件全載入到記憶體中了

所以，Sublime Text 也是很優秀，但是打開大文件，同樣一塌糊塗。

VSCode

編輯器界的新秀 VSCode 在大文件方面又能表現如何呢？

當我把文件拖入到 VSCode 時，彈出了如下提示

按照提示進行重啟後，再次嘗試打開文件

就一直處於載入中

載入一段時間後，又彈出了這個頁面

後又多次嘗試打開，均以失敗告終

所以，VSCode 打開大文件，失敗！

UltraEdit

現在再來試一下老牌的 UltraEdit，網上說它是可以打開大文件的，那我們就看下到底表現如何。

打開有了幾十秒的時間，並且打開過程中卡死

但是打開後，文件瀏覽起來還是很順滑的。

直接進行編輯好像也沒什麼問題

但是當我使用 ctrl+z 進行撤銷操作，或者進行文件保存時

還是卡住了

我們發現，其實 UltraEdit 記憶體佔用很小，這種情況下，仍然能夠順滑瀏覽大文件，難道是因為我的 SSD？

總之，UltraEdit 要比 Notepad++ 和 Sublime Text 表現要好多了。

EmEditor

好了，做了這麼多鋪墊，到了主角出現的時候了，它就是：EmEditor

EmEditor 是一個比較小眾的編輯器，當年實習時，只有當年實習時看到指導老師用過，此後多年，沒再看到過它的身影。

知乎上甚至還有一個問題：為什麼用 EmEditor 的人不多？

回答者對其的評價頗高，有人甚至稱其為：Windows平台下最棒的文本編輯工具！沒有之一！

評價都是『倖存者偏差』，我們不過多關注，到底怎樣，拉出來溜溜

1、載入大文件，沒有出現卡死的情況；

2、瀏覽文件，同樣順滑；

3、編輯大文件，不費力氣；

4、保存時，出現短暫卡死的情況；

總之，這是今天所有測試下來，大文件打開表現最優秀的一個。

總結

本文並沒有比較各個編輯器的意圖，所以對於各個編輯器的優劣不做評價。

本文只是實驗在大文件編輯的情況下，到底誰的表現更為突出。

綜合結論：EmEditor ≈ UltraEdit > Sublime Text ，VSCode 和 Notepad++ 無法打開大文件，不參與排名。

另外，也許還有其他更為優秀的工具，比如 Vim 其實也可以用來編輯大文件，小編認知有限，大家可以留言推薦。