1.新建查詢語句文件query.sql，內容如下:
--------------------------------------分割線----------------------------------------
         use appdb;
         set names utf8;
         select FeedID, City , Message  from Feed limit 1000;
--------------------------------------分割線----------------------------------------
上面的set names utf8語句是設施當前使用的編碼，如果編碼和數據庫的編碼不一致，會出現亂碼
      2.執行如下：
     [root@proxy tianqg]# mysql -uroot -p < query.sql > query.txt
回車，輸入密碼，在當前目錄下會產生查詢結果文件query.txt
      這些語句以前都是非常熟悉的，昨天有人問起，一時沒有給出準確的回答，命令行操作這種東西是容易忘記的，還是記下來備忘吧

      有個存儲過程，功能是：根據用戶名查詢非好友的ID，代碼如下：
 其中，pUserID是搜索者的UID,pUserName是要搜索的用戶名。今天發現這個存儲過程非常慢，分析結論是：not in 后面的select子查詢是每次都執行的，這出乎意料！mysql難道不能優化掉這樣的查詢嗎？
      后來用了臨時表的方案，如下：

問題較好的解決了，因為臨時表temp中保存的都是好友的ID，非常快，不用每次都去執行好友的篩選邏輯。另外一種方式是：將好友ID作為參數傳遞到存儲過程中，在程序外面查詢好友，但要改動程序。
 

     摘要: 最近幾天一直在思考一個問題：我們需要什么樣的網絡基礎開發包？libevent，asio，ace，還是自己封裝？Buffer類，內存池  閱讀全文

已經非常的陌生了，沒有網絡幾乎寫不了代碼了，準備寫個自用的抓包工具，可以指定某個應用來抓包，這樣抓到的包分析起來更具有針對性，常用工具wireshark雖然支持過濾規則，但是對走多協議的應用，比如tcp，udp，http都用的應用過濾起來比較吃力，WPE也不太合適，我想集成一些實用小工具，如網絡字節序的轉換，UTF8和GB的轉換等，如此則可以快速分析協議，所以索性自己寫個吧，網絡抓包這塊是做服務器的基本功，已經搞定了，界面的布局和實現方面還沒有確定，不用MFC好多年，希望這次嘗試算是一個新的開始。

     自從做公司的SNS社區以來，寫了不少的C#代碼，與C++相比，C#是易于使用的，開發效率提高很多倍，其中印象比較深刻的是，在一個C#工程中，可以通過向導添加配置文件，默認文件名為App.Config,是XML格式，一般內容為：
通過在appSettings里面添加add元素，即可實現通常的配置功能，更重要的是，可以進一步擴展為多級的樹形結構，與Ini格式相比，更直觀，可讀性更強，下面是基于CMarkup（http://www.firstobject.com/）的一個簡單實現：
頭文件如下：
源文件如下：

測試代碼為：

         CDR可以提供對基本數據類型如int，short，double，string等的序列化機制，簡單包裝后即可擔當RPC中的序列化角色。

假若有如下的demo.idl,內容如下：

      struct user_info
      {
            int user_id;
            string user_name;            
      }
利用idl_gen生成代碼時：
      (1)如果是侵入式的方案，則生成user_info類時，自動添加成員OutputCDR和InputCDR成員，并添加pack(ACE_Message_Block &* msg)和parse(ACE_Message_Block * msg)成員函數，在pack和parse里面，調到對于的CDR類，按照類中數據成員的聲明順序依次序列化，反序列化
      (2)如果是非侵入式方案，則生成user_info類時，生成獨立函數的pack(user_info& info, ACE_Message_Block &* msg)和parse(user_info& info,ACE_Message_Block * msg),pack和parse的函數實現同上

      wireshark（http://www.wireshark.org/）是我經常用到的抓包工具，這對于網絡程序的調試至關重要，特別是客戶端人員和服務端人員都認為自己的代碼沒問題時，wireshark本身是開源的，在windows平臺下基于 winpcap（http://www.winpcap.org/）開發的，安裝wireshark的時候，會提示在線安裝winpcap，今天在筆記本上用VS2008,編譯了Examples-pcap下面的basic_dump和basic_dump_ex，不曾想到的是抓不到包，甚是奇怪，因為用wireshark抓包是可以的，因此懷疑是不是哪個參數設施不對，終于比對wireshark，得出結論：將pcap_open_live的第四個參數設為0，即不能打開混雜模式，

if ((adhandle= pcap_open_live(d->name, // name of the device
        65536,   // portion of the packet to capture.
           // 65536 grants that the whole packet will be captured on all the MACs.
        0,    // promiscuous mode (nonzero means promiscuous)
        1000,   // read timeout
        errbuf   // error buffer
        )) == NULL)
 {
  fprintf(stderr,"\nUnable to open the adapter. %s is not supported by WinPcap\n", d->name);
  /* Free the device list */
  pcap_freealldevs(alldevs);
  return -1;
 }

   手冊上的說明：
   

   UNIX_TIMESTAMP(), UNIX_TIMESTAMP(date)

If called with no argument, returns a Unix timestamp (seconds since '1970-01-01 00:00:00' UTC) as an unsigned integer. If UNIX_TIMESTAMP() is called with a date argument, it returns the value of the argument as seconds since '1970-01-01 00:00:00' UTC. date may be a DATE string, a DATETIME string, a TIMESTAMP, or a number in the format YYMMDD or YYYYMMDD. The server interprets date as a value in the current time zone and converts it to an internal value in UTC. Clients can set their time zone as described in Section 5.11.8, “MySQL Server Time Zone Support”.

      這里的UNIX_TIMESTAMP()的返回值和C函數time(NULL)的返回值含義一樣，
  mysql> select UNIX_TIMESTAMP();
+------------------+
| UNIX_TIMESTAMP() |
+------------------+
|       1292815556 |
+------------------+
1 row in set

mysql> select FROM_UNIXTIME(1292815556);
+---------------------------+
| FROM_UNIXTIME(1292815556) |
+---------------------------+
| 2010-12-20 11:25:56       |
+---------------------------+
1 row in set

終于碰到這個問題了，原文鏈接：http://hi.baidu.com/zzy_cqok/blog/item/46ee33998777f3056f068c2b.html

vs2008調試后控制臺窗口關不了2010-07-29 16:19
最近用Visual Studio 2008 寫一些控制臺程序，調試后的時候，當走到完成的時候，這個控制臺程序的窗口就關不了了。再調試的時候就會出現一個新的控制臺程序。
在任務管理器還可以看到這個窗口，但是關不掉了。感覺這個控制臺程序已經失控了。
雖然這個對電腦運行沒有影響，但還是很不爽。而且最后關機還有問題，導致不能關機。
找到一些相關的網頁也討論的，最后結論是windows的一個更新KB978037導致cress.exe出了一些問題。
解決辦法：刪除KB978037更新，刪除的辦法是在控制面板的添加或刪除程序面板里，勾選顯示更新，找到KB978037更新，刪除。
附別人的討論記錄：http://social.msdn.microsoft.com/Forums/en-US/vsdebug/thread/e6d4a4f5-7002-401a-90e1-6174d7f9e3ca/
 

http://www.boostpro.com/download/
目前只有windows平臺的，而且是32位