我們在打ctf時候，出題的爺爺們給出的exe都很小 就10k左右，有的甚至就5k，那時候我很鬱悶啊。現在我也能了啊哈哈
不多bb按如下操作：
不得不說 我們在程式裡並沒有寫太多東西，36kb的值確實有點大了。接下來我們開始壓縮
#include "windows.h"
#pragma comment(linker,"/opt:nowin98")
int main()
build後結果如下：現在已經減小10k了
按如下步驟進行
結果如下：不得不說現在只剩下3kb了。而且程式執行一切正常。
現在這個程式已經很小了，舒服~
表的資料量特別大時是怎麼處理的
1 索引優化和sql語句優化是必須的，避免模糊查詢和非索引查詢，刪改操作根據聚集索引進行，刪改操作太頻繁的話還是需要考慮分表 2 看需求，如果需求不限制，那就分表 分割槽會增加管理複雜度和成本這個很難理解，分割槽增加不了多少工作，如果需求要求必須單錶，分割槽是解決在千萬到幾億資料量的比較合適的方法 ...
問題3 生產環境中的 redis 是怎麼部署的？
生產環境中的 redis 是怎麼部署的？分析 看看你了解不了解你們公司的 redis 生產集群的部署架構，如果你不了解，那麼確實你就很失職了，你的 redis 是主從架構？集群架構？用了哪種集群方案？有沒有做高可用保證？有沒有開啟持久化機制確保可以進行資料恢復？線上 redis 給幾個 g 的記憶體...
在CTF中的小端序與大端序
大，人類為大。所以這是符合人的思維的。即高位址放資料低位 eg 位址從低到高的表示方式 12 34 12是低位址，但是為了人方便看，把資料的高位放在了低位址，這樣子看起來的順序還是 1234。方便看。小端序 是為了計算機效率的。即高位址放資料高位。高高低低。之前我走進了乙個誤區 將陣列也當作位元組序...