trx內核
Ⅰ 如何在OpenWrt下做驅動開發
1、搭建開發環境
首先，在執行make menuconfig後，會出現下圖：
其中，圖中紅框部分是我定製路由器的系統版本，大家可以根據不同的路由器進行不同的選擇；綠框部分表示我們需要編譯一個SDK開發環境（默認情況下，此項未勾選）。
編譯過程中需要通過官網下載很多相關的軟體包，所以必須保證能夠順利連上外網。由於下載速度的限制，編譯過程大概需要數小時。編譯結束後，所有的產品都會放在編譯根目錄下的bin/yourtarget/. 例如:我所編譯的產物都放在./bin/brcm47xx/下，其中文件主要有幾類：
（1）.bin/.trx 文件: 這些都是在我們所選的target-system的類別之下，針對不同路由器型號、版本編譯的路由器固件。這些不同路由器的型號和版本是openwrt預先設置好的，我們不需要更改。至於.bin和.trx的區別，一種說法是，第一次刷路由器的時候，需要用.bin文件，如果需要再升級，則不能再使用.bin文件，而需要用.trx文件。原因是，.bin是將路由器的相關配置信息和.trx封裝在一起而生成的封包，也就是說是包含路由器版本信息的.trx。在第一次刷固件的時候，我們需要提供這樣的信息，而在後續升級時，則不再需要，用.trx文件即可。
（2）packages文件夾: 裡麵包含了我們在配置文件里設定的所有編譯好的軟體包。默認情況下，會有默認選擇的軟體包。
（3）OpenWrt-SDK.**.tar.bz2: 這個也就是我們定製編譯好的OpenWRT SDK環境。我們將用這個來進行OpenWrt軟體包的開發。例如，我所編譯好的SDK環境包為：/bin/brcm47xx/OpenWrt-SDK-brcm47xx-for-Linux-x86_64-gcc-4.3.3+cs_uClibc-0.9.30.1.tar.bz2
可以從名稱上看出，target system是brcm47xx，host system是Linux-x86_64，使用的編譯工具以及庫是4.3.3+cs_uClibc-0.9.30.1。
（4）md5sums 文件: 這個文件記錄了所有我們編譯好的文件的MD5值，來保證文件的完整性。因為文件的不完整，很容易將路由器變成「磚頭」。
需要主要的是，編譯完成後，一定要將編譯好的bin目錄進行備份（如果裡面東西對你很重要的話），因為在下次編譯之前，執行make clean 會將bin目錄下的所有文件給清除掉!!
2、 更改原有packages
在編譯根目錄下會有一個dl的目錄，這個目錄其實是「download」的簡寫，在編譯前期，需要從網路下載的數據包都會放在這個目錄下，這些軟體包的一個特點就是，會自動安裝在所編譯的固件中，也就是我們make menuconfig的時候，為固件配置的一些軟體包。如果我們需要更改這些源碼包，只需要將更改好的源碼包打包成相同的名字放在這個目錄下，然後開始編譯即可。編譯時，會將軟體包解壓到build_dir目錄下。
當然，你也可以自己在dl裡面創建自己的軟體包，然後更改相關的配置文件，讓openwrt可以識別這個文件包。
由於我的項目更改的內容是底層的，需要跟固件一起安裝。所以，我使用的方法就是直接更改dl目錄下軟體包，然後重新進行固件編譯。感覺類似於Linux的內核編譯。反復編過十多次，沒有任何問題。
3、 新建自己的packages
對於自己新建的package，而這個package又不需要隨固件一起安裝，換句話說，就是可以當做一個可選軟體包的話。我們可以利用我們的SDK環境來單獨編譯，編譯後會生成一個ipk的文件包。然後利用 opkg install xxx.ipk 來安裝這個軟體。
下面具體說下，如何編譯一個helloword的軟體包。
（1）首先，編寫helloworld程序
編寫helloworld.c
/****************
* Helloworld.c
* The most simplistic C program ever written.
* An epileptic monkey on crack could write this code.
*****************/
#include <stdio.h>
#include <unistd.h>
int main(void)
{
printf("Hell! O' world, why won't my code compile?\n\n");
return 0;
}
編寫Makefile文件
# build helloworld executable when user executes "make"
helloworld: helloworld.o
$(CC) $(LDFLAGS) helloworld.o -o helloworld
helloworld.o: helloworld.c
$(CC) $(CFLAGS) -c helloworld.c
# remove object files and executable when user executes "make clean"
clean:
rm *.o helloworld
在這兩個文件的目錄下，執行make 應該可以生成helloworld的可執行文件。執行helloworld後，能夠列印出「Hell! O' world, why won't my code compile?」。 這一步，主要保證我們的源程序是可以正常編譯的。下面我們將其移植到OpenWRT上。
（2）將OpenWrt-SDK-brcm47xx-for-Linux-x86_64-gcc-4.3.3+cs_uClibc-0.9.30.1.tar.bz2解壓
tar –xvf OpenWrt-SDK-brcm47xx-for-Linux-x86_64-gcc-4.3.3+cs_uClibc-0.9.30.1.tar.bz2
（3）進入SDK
cd OpenWrt-SDK-brcm47xx-for-Linux-x86_64-gcc-4.3.3+cs_uClibc-0.9.30.1
可以看到裡面的目錄結構跟我們之前source的目錄結構基本相同，所需要編譯的軟體包，需要放置在package目錄下
（4）在package目錄下創建helloworld目錄
cd package
mkdir helloworld
cd helloworld
（5）創建src目錄，拷貝 helloworld文件
mkdir src
cp /home/wrt/test/helloworld.c src
cp /home/wrt/test/Makefile src
（6）在helloworld目錄下創建Makefile文件
這個Makefile文件是給OpenWRT讀的，而之前寫的那個Makefile文件是針對helloworld給編譯其讀的。兩個Makefile不在同一層目錄下。
touch Makefile
vim Makefile
Makefile文件模板內容如下：
##############################################
# OpenWrt Makefile for helloworld program
#
#
# Most of the variables used here are defined in
# the include directives below. We just need to
# specify a basic description of the package,
# where to build our program, where to find
# the source files, and where to install the
# compiled program on the router.
#
# Be very careful of spacing in this file.
# Indents should be tabs, not spaces, and
# there should be no trailing whitespace in
# lines that are not commented.
#
##############################################
include $(TOPDIR)/rules.mk
# Name and release number of this package
PKG_NAME:=helloworld
PKG_RELEASE:=1
# This specifies the directory where we're going to build the program.
# The root build directory, $(BUILD_DIR), is by default the build_mipsel
# directory in your OpenWrt SDK directory
PKG_BUILD_DIR := $(BUILD_DIR)/$(PKG_NAME)
include $(INCLUDE_DIR)/package.mk
# Specify package information for this program.
# The variables defined here should be self explanatory.
# If you are running Kamikaze, delete the DESCRIPTION
# variable below and uncomment the Kamikaze define
# directive for the description below
define Package/helloworld
SECTION:=utils
CATEGORY:=Utilities
TITLE:=Helloworld -- prints a snarky message
endef
# Uncomment portion below for Kamikaze and delete DESCRIPTION variable above
define Package/helloworld/description
If you can't figure out what this program does, you're probably
brain-dead and need immediate medical attention.
endef
# Specify what needs to be done to prepare for building the package.
# In our case, we need to the source files to the build directory.
# This is NOT the default. The default uses the PKG_SOURCE_URL and the
# PKG_SOURCE which is not defined here to download the source from the web.
# In order to just build a simple program that we have just written, it is
# much easier to do it this way.
define Build/Prepare
mkdir -p $(PKG_BUILD_DIR)
$(CP) ./src/* $(PKG_BUILD_DIR)/
endef
# We do not need to define Build/Configure or Build/Compile directives
# The defaults are appropriate for compiling a simple program such as this one
# Specify where and how to install the program. Since we only have one file,
# the helloworld executable, install it by ing it to the /bin directory on
# the router. The $(1) variable represents the root directory on the router running
# OpenWrt. The $(INSTALL_DIR) variable contains a command to prepare the install
# directory if it does not already exist. Likewise $(INSTALL_BIN) contains the
# command to the binary file from its current location (in our case the build
# directory) to the install directory.
define Package/helloworld/install
$(INSTALL_DIR) $(1)/bin
$(INSTALL_BIN) $(PKG_BUILD_DIR)/helloworld $(1)/bin/
endef
# This line executes the necessary commands to compile our program.
# The above define directives specify all the information needed, but this
# line calls BuildPackage which in turn actually uses this information to
# build a package.
$(eval $(call BuildPackage,helloworld))
（7）返回到SDK的根目錄
執行make進行編譯
編譯過程會在build_dir目錄下完成
編譯結果會放在 bin/[yourtarget]/package目錄下helloworld_1_bcm47xx.ipk
（8）上傳helloworld_1_bcm47xx.ipk
使用sftp軟體上傳helloworld_1_bcm47xx.ipk至路由器
執行 opkg install helloworld_1_bcm47xx.ipk
輸入hello然後按Tab鍵，發現openwrt中已經有helloworld可執行命令。
執行 helloworld 查看程序的效果。
Hell! O' world, why won't my code compile?
【End】
希望對大家能有幫助 :)
轉載
Ⅱ 如何將一個現成的ipk加入到openwrt編譯出的固件中
（!文末附加戲寫編譯OPENWRTTXT內容直接跳至末尾例）
Openwrt 官式發行版已編譯映像文件（綴名bin或trx、trx2）映像文件Openwrt官網站載頁面輕松獲取連接址 OpenWrt官網站些編譯映像文件基於默認配置設置且針受支持平台或設備要打造自映像文件理由四點：
您想擁性化配置OpenWrt（彰顯性朋友圈顯擺顯擺玩笑）；
您想實驗性平台測試OpenWrt；
您參與測試或參與發OpenWrt工作；
或者簡單目保持自Openwrt新版本；
若想實現述目其實簡單按述文字即功編譯您Openwrt
准備工作
始編譯Openwrt前需要您做些准備工作；與其編譯程類似編譯工具編譯環境必少：
構建OpenWrt映像系統平台簡單說准備操作系統（比Ubuntu、Debian等）；
確保安裝所需依賴關系庫 （debian系統安裝各種需要軟體包）
OpenWrt源代碼副本
首先 機登陸支持編譯Openwrt操作系統（廢）實體機或者虛擬機(Vmware 或者 Qemu)操作系統都行推薦使用Linux系統 bsdmac osx系統編推薦且未驗證否編譯功文假定您使用Debian操作系統使用 apt-get 管理包. 替代選擇 Ubuntu (支 Kubuntu, Xubuntu 等即)
第二步, 安裝所需要各種軟體包, 包括編譯器,解壓工具,特定庫等. 些工作簡單通鍵入命令 (通需要root 或者 sudo 許可權)root許可權安裝列軟體包(能並完整提示提示缺少即裝）:
32位(x86)請執行列命令:
# apt-get install build-essential asciidoc binutils bzip2 gawk gettext \
git libncurses5-dev libz-dev patch unzip zlib1g-dev
64位(x86_64)請執行列命令（裝哪些庫或軟體包呢請您仔細看看哦）:
# apt-get install build-essential asciidoc binutils bzip2 gawk gettext \
git libncurses5-dev libz-dev patch unzip zlib1g-dev ia32-libs \
lib32gcc1 libc6-dev-i386
參考 本列表 所列編譯環境所需要軟體包或庫
某些依賴庫或軟體包許操作系統已經安裝apt-get作提示（提示您忽略或重新安裝）別緊張放輕鬆些編譯Openwrt像編譯DD－WRT難（至少本體編譯DD－WRT難）
載份完整 Openwrt 源碼編譯環境關於Openwrt源代碼載途徑二通 svn 通 git建議使用 svn Openwrt主要 svn 維護Openwrt系統版本另外請注意Openwrt同支版本用較發快照俗稱 trunk二穩定版俗稱 backfire
安裝Subversion
若想通svn載源代碼,需安裝 SubversionSubversion,或稱SVN, OpenWrtproject用控製版本系統,非類似 CVS界面使用條款 執行述命令即安裝SVN容易：
# apt-get install subversion
Subversion安裝完畢通SVN命令獲取份OpenWrt純凈源代碼您創建目錄便存放獲取Openwrt源代碼要獲取源代碼輸入subversion命令獲取 (svn種操作稱'check out') 命令簡單繼續看能見別著急耐點
編譯流程
編譯專屬於您設備特定Openwrt固件五步驟：
通Subversion命令獲源代碼；
更新(或安裝) package feeds［package feeds確切翻譯待譯吧）；
創建默認配置檢查編譯環境否搭建 (假需要)；
用Menuconfig配置即編譯固件映像文件配置項；
始編譯固件；
載源代碼
載份完整OpenWrt源代碼選擇：
載穩定發行版或
載發版 (俗稱"trunk"版)
使用發行版源碼
截止本文, Openwrt公發行穩定版 OpenWrt 10.03 "backfire"版本穩定許包括新更新補丁或新編寫新功能
述代碼即舉例說明通svnbrandkfire獲backfire源代碼（版本意思trunk支補丁backfire版本即包含修復補丁）：
# mkdir OpenWrt/
# cd OpenWrt/
# svn co svn://svn.openwrt.org/openwrt/branches/backfire
註解: 述svn命令前目錄創建 OpenWrt/backfire/ 目錄目錄包含命令獲取源代碼
您通述命令載含修復補丁backfire原版源碼：
# svn co svn://svn.openwrt.org/openwrt/tags/backfire_10.03
使用發版源代碼
前發版本支(trunk)已包含新實驗補丁支或許突破Openwrt原所支持硬體設備限制哦驚喜同風險存編譯trunk版慎～
# mkdir OpenWrt/
# cd OpenWrt/
# svn co svn://svn.openwrt.org/openwrt/trunk/
更詳細資料詳見：
跟進並更新源代碼
Openwrt源代碼隨都變故命令確保您所獲取源碼新性述假設您用backfire版本源碼：
## Here, backfire is the directory name of the current release branch you're tracking
# cd OpenWrt/backfire/
# svn up
'svn up' 命令用於更新SVN更新本尚未更新部源代碼（本實踐證明命令本源碼與SVN源碼先比較若SVN更新才載更新部實用命令）未指定目標路徑則命令更新前目錄及前目錄目錄內源碼
Feeds載
Feeds即包含OpenWrt環境額外軟體包索引類（feed譯名莫衷至2008底止沒十通用備受認文譯名；所文我用英文feed稱呼） 主要Feeds三：
'packages' - 路由基本功能,
'LuCI' - OpenWrt默認GUI（WEB管理界面）, 及
'Xwrt' - 其GUI
般情況至少需要含 'packages' 'LuCI'兩Feeds
載完feeds (編譯OpenWrtrecipies額外預定義包) 您檢查哪些feeds要包括內編輯編譯環境根目錄'feeds.conf.default'文件
使用列命令始載（註：能需要先運行cd trunk進入trunk目錄才能功執行列命令）：
# ./scripts/feeds update -a
載軟體包需要安裝亦即指邊命令啦若路邊install命令則續make menuconfig功執行（註：能需要先運行cd trunk進入trunk目錄才能功執行列命令）：
# ./scripts/feeds install -a
需編輯Feeds配置文件或運行更新命令即便更新或添加新實驗性packages源碼並編譯OpenWrt固件
注意：請壇友及舊新聞組員注意步取代創建符號鏈接symlinks辦哦
更新Feeds
諸類源碼,定期更新Feeds 通相同命令:
# ./scripts/feeds update -a
# ./scripts/feeds install -a
注意:若清楚知道需添加新packagesmenuconfig更新Feeds跳步
配置
You may not have to make configration always after updating sources and feeds, but making it ensures that all packages from source and feeds are correctly included in your build configuration.
Defconfig
步檢查編譯環境若進行編譯則默認配置：
# make defconfig
若defconfig顯提示缺少軟體包或編譯庫等依賴則按提示安裝所缺軟體包或庫等即難細點行
Menuconfig
menuconfig基於文本工具處理選擇目標（需要需要）、編譯軟體包（openwrtIPKG格式）及內核選項（編譯模塊內核）等等
# make menuconfig
離並保存配置文件（默認都.config）自配置依賴關系讓著手編譯更新固件
眾通'menuconfig'簡單圖形化配置環境非輕松編譯專屬您本OpenWrt固件
用'menuconfig'發意圖編譯OpenWrt固件自（）創造結構簡單功能強環境（句實難翻譯能意譯並且請家都習編譯OP固件讓OP固件盈利丟掉骯臟飯碗）
Menuconfig或或少些難說明即使專業配置尋求幫助並加解決 需要指定何種目標平台要包含package軟體包內核模塊等均需要指定配置標准程包括修改：
目標平台（即路由器何種架構BCM呢AR均選擇）
選擇要包含package軟體包
構建系統設置
內核模塊
Target system is selected from the extensive list of supported platforms, with the numerous target profiles – ranging from specific devices to generic profiles, all depending on the particular device at hand. Package selection has the option of either 'selecting all package', which might be un-practical in certain situation, or relying on the default set of packages will be adequate or make an indivial selection. It is here needed to mention that some package combinations might break the build process, so it can take some experimentation before the expected result is reached. Added to this, the OpenWrt developers are themselves only maintaining a smaller set of packages – which includes all default packages – but, the feeds-script makes it very simple to handle a locally maintained set of packages and integrate them in the build-process.
假需要LuCI, 要Administration 菜單,LuCI組件菜單, 並選擇: luci-admin-core, luci-admin-full, and luci-admin-mini組件包
假需要PPP,Network菜單取消選擇便編譯包含組件
Menuconfig用: 確保些組件包 '*'星號標記 'M'標記
星號 '*'標記該組件包, 則該組件包編譯進終OpenWrt固件
僅 'M'標記該組件包, 則該組件包編譯進終OpenWrt固件
The final step before the process of compiling the intended image(s) is to exit 'menuconfig' – this also includes the option to save a specific configuration or load an already existing, and pre-configured, version.
Exit and save.
Source Mirrors
The 'Build system settings' include some efficient options for changing package locations which makes it easy to handle a local package set:
Local mirror for source packages
Download folder
In the case of the first option, you simply enter a full URL to the web or ftp server on which the package sources are hosted. Download folder would in the same way be the path to a local folder on the build system (or network). If you have a web/ftp-server hosting the tarballs, the OpenWrt build system will try this one before trying to download from the location(s) mentioned in the Makefiles . Similar if a local 'download folder', residing on the build system, has been specified. The 'Kernel moles' option is required if you need specific (non-standard) drivers and so forth – this would typically be things like moles for USB or particular network interface drivers etc.
編譯固件
萬事具備欠東風,通面簡單make命令編譯:
# make
核電腦編譯
具核CPU處理器電腦進行編譯使用述參數令編譯程加速 規用 – 例使用3進程編譯 (即雙核CPU), 命令及參數:
# make -j 3
台編譯
若系統內編譯OpenWrt同處理其讓閑置I/O及CPU台編譯固件 (雙核CPU):
# ionice -c 3 nice -n 20 make -j 2
編譯簡單基本軟體包
OpenWrt發或打包軟體包,編譯簡單基本軟體包輕易編譯該軟體包 (例 軟體包cups):
# make package/cups/compile V=99
Feeds軟體包約:
# make package/feeds/packages/ndyndns/compile V=99
編譯錯誤
某種知道原編譯失敗,面種簡單知編譯底錯哪:
# make V=99 2>&1 |tee build.log |grep -i error
述編譯命令意：V99參數錯信息保存build.log輸完整詳細副本（with stdout piped to stderr）屏幕顯示錯誤
舉例說明:
# ionice -c 3 nice -n 20 make -j 2 V=99 CONFIG_DEBUG_SECTION_MISMATCH=y 2>&1 \
|tee build.log |egrep -i '(warn|error)'
The above saves a full verbose of the build output (with stdout piped to stderr) in build.log and outputs only warnings and errors while building using only background resources on a al core CPU.
Ⅲ 哪裡能找到關於TD-SCDMA基站相關的詳細資料
關於TD-SCDMA基站相關的詳細資料
單片機系統的低功耗設計策略
作 者：清華大學 陳萌萌 邵貝貝
摘要：嵌入式系統的低功耗設計需要全面分析各方面因素，統籌規劃。在設計之初，各個因素往往是相互制約、相互影響的，一個降低系統功耗的措施有時會帶來其他方面的「負效應」。因此，降低系統整體功耗，需要仔細分析和計算。本文從硬體和應用軟體設計兩個方面，闡述一個以單片機為核心的嵌入式系統低功耗設計時所需考慮的一些問題。
關鍵詞：低功耗設計 硬體設計 應用軟體設計 低功耗模式
在嵌入式應用中，系統的功耗越來越受到人們的重視，這一點對於需要電池供電的攜帶型系統尤其明顯。降低系統功耗，延長電池的壽命，就是降低系統的運行成本。對於以單片機為核心的嵌入式應用，系統功耗的最小化需要從軟、硬體設計兩方面入手。
隨著越來越多的嵌入式應用使用了實時操作系統，如何在操作系統層面上降低系統功耗也成為一個值得關注的問題。限於篇幅，本文僅從硬體設計和應用軟體設計兩個方面討論。
1 硬體設計
選用具有低功耗特性的單片機可以大大降低系統功耗。可以從供電電壓、單片機內部結構設計、系統時鍾設計和低功耗模式等幾方面考察一款單片機的低功耗特性。
1.1 選用盡量簡單的CPU內核
在選擇CPU內核時切忌一味追求性能。8位機夠用，就沒有必要選用16位機，選擇的原則應該是「夠用就好」。現在單片機的運行速度越來越快，但性能的提升往往帶來功耗的增加。一個復雜的CPU集成度高、功能強，但片內晶體管多，總漏電流大，即使進入STOP狀態，漏電流也變得不可忽視；而簡單的CPU內核不僅功耗低，成本也低。
1.2 選擇低電壓供電的系統
降低單片機的供電電壓可以有效地降低其功耗。當前，單片機從與TTL兼容的5 V供電降低到3.3 V、3 V、2 V乃至1.8 V供電。供電電壓降下來，要歸功於半導體工藝的發展。從原來的3 μm工藝到現在的0.25、0.18、0.13 μm工藝， CMOS電路的門限電平閾值不斷降低。低電壓供電可以大大降低系統的工作電流，但是由於晶體管的尺寸不斷減小，管子的漏電流有增大的趨勢，這也是對降低功耗不利的一個方面。
目前，單片機系統的電源電壓仍以5 V為主，而過去5年中，3 V供電的單片機系統數量增加了1倍，2 V供電的系統也在不斷增加。再過五年，低電壓供電的單片機數量可能會超過5 V電壓供電的單片機。如此看來，供電電壓降低將是未來單片機發展的一個重要趨勢。
1.3 選擇帶有低功耗模式的系統
低功耗模式指的是系統的等待和停止模式。處於這類模式下的單片機功耗將大大小於運行模式下的功耗。過去傳統的單片機，在運行模式下有wait和stop兩條指令，可以使單片機進入等待或停止狀態，以達到省電的目的。
等待模式下，CPU停止工作，但系統時鍾並不停止，單片機的外圍I/O模塊也不停止工作；系統功耗一般降低有限，相當於工作模式的50%～70%。
停止模式下，系統時鍾也將停止，由外部事件中斷重新啟動時鍾系統時鍾，進而喚醒CPU繼續工作，CPU消耗電流可降到μA級。在停止模式下，CPU本身實際上已經不消耗什麼電流，要想進一步減小系統功耗，就要盡量將單片機的各個I/O模塊關掉。隨著I/O模塊的逐個關閉，系統的功耗越來越小，進入停止模式的深度也越來越深。進入深度停止模式無異於關機，這時的單片機耗電可以小於20 nA。其中特別要提示的是，片內RAM停止供電後，RAM中存儲的數據會丟失，也就是說，喚醒CPU後要重新對系統作初始化。因此在讓系統進入深度停止狀態前，要將重要系統參數保存在非易失性存儲器中，如EEPROM中。深度停止模式關掉了所有的I/O，可能的喚醒方式也很有限，一般只能是復位或IRQ中斷等。
保留的I/O模塊越多，系統允許的喚醒中斷源也就越多。單片機的功耗將根據保留喚醒方式的不同，降至1μA至幾十μA之間。例如，用戶可以保留外部鍵盤中斷，保留非同步串列口（SCI）接收數據中斷等來喚醒CPU。保留的喚醒方式越多，系統耗電也就會多一些。其他可能的喚醒方式還有實時鍾喚醒、看門狗喚醒等。停機狀態較淺的情況下，外部晶振電路還是工作的。
圖1以Freescale的HCS08單片機為例，給出不同運行模式下的系統功耗。HCS08是8位單片機，有多個系列，各系列I/O模塊數目有所不同，但低功耗模式下的電流消耗大致相同。
圖1HCS08單片機各模式下的耗電
以R系列單片機為例：在室溫（25℃）下，不包括I/O口的負載，以2 V供電，將可編程鎖相環時鍾設為16 MHz（匯流排時鍾8 MHz），典型電流值為2.6 mA，當溫度升高到85℃時，供電電流也升高到3.6 mA；而採用3 V供電，這一組數據升高至3.8 mA和4.8 mA。用2 V供電，直接使用外部晶振2 MHz（匯流排時鍾1 MHz）時，典型運行電流降至450 μA。在等待狀態下，因時鍾並沒有停止，耗電情況和時鍾頻率有很大關系，節省的功耗有限；而進入輕度停止（stop3），以外部中斷喚醒，電流消耗在0. 5 μA左右。在中度停止態（stop2），功耗可進一步降低。使用內部1 kHz的時鍾，保持1個運行的時鍾，周期性喚醒CPU，所增加的電流約為0.3 μA。在深度停止態（stop1），RAM的數據也不再保留，只能通過外部復位重啟系統，此時的電流消耗可降到20 nA。以上數據都是在室溫下測量所得。當環境溫度升高到85℃時，電流消耗可能增加3～5倍。
1.4選擇合適的時鍾方案
時鍾的選擇對於系統功耗相當敏感，設計者需要注意兩個方面的問題：
第一是系統匯流排頻率應當盡量低。單片機內部的總電流消耗可分為兩部分——運行電流和漏電流。理想的CMOS開關電路，在保持輸出狀態不變時，是不消耗功率的。例如，典型的CMOS反相器電路，如圖2所示，當輸入端為零時，輸出端為1，P晶體管導通，N晶體管截止，沒有電流流過。而實際上，由於N晶體管存在一定漏電流，且隨集成度提高，管基越薄，漏電流會加大。溫度升高，CMOS翻轉閾電壓會降低，而漏電流則隨環境溫度的增高變大。在單片機運行時，開關電路不斷由「1」變「0」、由「0」變「1」，消耗的功率是由單片機運行引起的，我們稱之為「運行電流」。如圖2所示，在兩只晶體管互相變換導通、截止狀態時，由於兩只管子的開關延遲時間不可能完全一致，在某一瞬間會有兩只管子同時導通的情況，此時電源到地之間會有一個瞬間較大的電流，這是單片機運行電流的主要來源。可以看出，運行電流幾乎是和單片機的時鍾頻率成正比的，因此盡量降低系統時鍾的運行頻率可以有效地降低系統功耗。
圖2典型的CMOS反相器
第二是時鍾方案，也就是是否使用鎖相環、使用外部晶振還是內部晶振等問題。新一代的單片機，如飛思卡爾的HCS08系列單片機，片內帶有內部晶振，可以直接作為時鍾源。使用片內晶振的優點是可以省掉片外晶振，降低系統的硬體成本；缺點是片內晶振的精度不高（誤差一般在25%左右，即使校準之後也可能有2%的相對誤差），而且會增加系統的功耗。
現代單片機普遍採用鎖相環技術，使單片機的時鍾頻率可由程序控制。鎖相環允許用戶在片外使用頻率較低的晶振，可以很大地減小板級雜訊；而且，由於時鍾頻率可由程序控制，系統時鍾可以在一個很寬的范圍內調整，匯流排頻率往往能升得很高。但是，使用鎖相環也會帶來額外的功率消耗。
單就時鍾方案來講，使用外部晶振且不使用鎖相環是功率消耗最小的一種。
2 應用軟體方面的考慮
之所以使用「應用軟體」的說法，是為了區分於「系統軟體」或者「實時操作系統」。軟體對於一個低功耗系統的重要性常常被人們忽略。一個重要的原因是，軟體上的缺陷並不像硬體那樣容易發現，同時也沒有一個嚴格的標准來判斷一個軟體的低功耗特性。盡管如此，設計者仍需盡量將應用的低功耗特性反映在軟體中，以避免那些「看不見」的功耗損失。
2.1 用「中斷」代替「查詢」
一個程序使用中斷方式還是查詢方式對於一些簡單的應用並不那麼重要，但在其低功耗特性上卻相去甚遠。使用中斷方式，CPU可以什麼都不做，甚至可以進入等待模式或停止模式；而查詢方式下，CPU必須不停地訪問I/O寄存器，這會帶來很多額外的功耗。
2.2 用「宏」代替「子程序」
程序員必須清楚，讀RAM會比讀Flash帶來更大的功耗。正是因為如此，低功耗性能突出的ARM在CPU設計上僅允許一次子程序調用。因為CPU進入子程序時，會首先將當前CPU寄存器推入堆棧（RAM），在離開時又將CPU寄存器彈出堆棧，這樣至少帶來兩次對RAM的操作。因此，程序員可以考慮用宏定義來代替子程序調用。對於程序員，調用一個子程序還是一個宏在程序寫法上並沒有什麼不同，但宏會在編譯時展開，CPU只是順序執行指令，避免了調用子程序。唯一的問題似乎是代碼量的增加。目前，單片機的片內Flash越來越大，對於一些不在乎程序代碼量大一些的應用，這種做法無疑會降低系統的功耗。
2.3 盡量減少CPU的運算量
減少CPU運算的工作可以從很多方面入手：將一些運算的結果預先算好，放在Flash中，用查表的方法替代實時的計算，減少CPU的運算工作量，可以有效地降低CPU的功耗（很多單片機都有快速有效的查表指令和定址方式，用以優化查表演算法）；不可避免的實時計算，算到精度夠了就結束，避免「過度」的計算；盡量使用短的數據類型，例如，盡量使用字元型的8位數據替代16位的整型數據，盡量使用分數運算而避免浮點數運算等。
2.4 讓I/O模塊間歇運行
不用的I/O模塊或間歇使用的I/O模塊要及時關掉，以節省電能。RS232的驅動需要相當的功率，可以用單片機的一個I/O引腳來控制，在不需要通信時，將驅動關掉。不用的I/O引腳要設置成輸出或設置成輸入，用上拉電阻拉高。因為如果引腳沒有初始化，可能會增大單片機的漏電流。特別要注意有些簡單封裝的單片機沒有把個別I/O引腳引出來，對這些看不見的I/O引腳也不應忘記初始化。
3 結論
一個成功的低功耗設計應該是硬體設計和軟體設計的結合。從硬體設計開始，就應該充分意識到一個低功耗應用的特性，選擇一款合適的單片機，通過對其特性的了解，設計系統方案；在軟體設計上，要考慮到低功耗編程的特殊性，並盡量使用單片機的低功耗模式。
限於篇幅，僅僅討論了低功耗設計中的一些常見問題，更多的問題只能靠設計者去實際分析和解決了。
參考文獻
1 劉慧銀，等. Motorola微控制器MC68HC08原理及其嵌入式應用，北京：清華大學出版社，2001
2 邵貝貝. 單片機嵌入式應用的在線開發方法. 北京：清華大學出版社，2004
3 Donnie Garcia, Scott Pape. MC9S08GB/GT Low�Power Modes. Freescale Semiconctor, Rev2. 2004
4 MC9S08GB/GT Data Sheet. Freescale Semiconctor, Rev.2.2, 2004
5 HCS08 Family Reference Manual. Freescale Semiconctor, 2003
6 Scott Pape. HC08 to HCS08 Transition. Freescale Semiconctor, 2004
7 Bill Lucas, Scott Pape. Configuring the System and Peripheral Clocks in the MC9S08GB/GT. Freescale Semiconctor, 2003
8 Scott Pape. S08 in Low Power Devices. Freescale Technology Forum, 2005
（收稿日期：2005-09-26）
2006.3.23 14:39作者:森
【引用：0 】【收藏】【評論：0】
LRE技術在數據通信組網中的應用
分類:技術文摘
http://www.ed-china.com/ART_8800014533_400010_500006_TS.HTM
LRE技術在數據通信組網中的應用
LRE技術簡介
長距離乙太網(LRE) 是Analogix自主創新的一項乙太網革新技術。該技術在保證傳輸速率的前提下，將傳統乙太網的最大傳輸距離由標準的100米提高到1000米 (10M)或者300米(100M)。ANX58xx系列晶元是Analogix推出的長距離乙太網PHY或者Converter，晶元全面兼容 IEEE802.3乙太網標准，可以作為常規的10Base-T，100Base-TX和100Base-FX的乙太網PHY使用；同時，晶元在完全兼容 IEEE802.3標准自協商協議的基礎上，擴充了長距離模式，使乙太網的傳輸距離突破了1000米，傳輸介質可適用於5類線、3類線、市話音頻電纜等。 LRE晶元與普通PHY相比，具有傳輸距離長，抗干擾能力強等明顯的優點，具有更廣泛的應用。本文將重點描述LRE技術在數據通信領域的各種應用。
LRE技術在「最後一公里」接入中的應用
寬頻用戶的迅猛發展，主要得益於乙太網技術的廣泛應用和網路設備成本的不斷降低，乙太網交換設備的應用已不僅僅局限在「區域網」，在「城域網」領域也得到規模應用。目前乙太網已經成為企事業用戶的主導接入方式，全球企事業用戶的80％以上都採用乙太網接入技術。在「最後一公里」接入技術中，乙太網技術通常應用在居民小區、高檔住宅樓和商業大廈，採用FTTx+LAN的接入方式，即將光纖建設到小區或大樓，再通過快速乙太網連接到用戶。用戶側的接入設備(如乙太網交換機，寬窄帶綜合接入設備等)一般位於小區或商業大樓內，向用戶提供業務介面，實現寬頻的接入。
在小區內或者商業區內，如何將光纖接入點與住宅和樓宇連接起來，是網路提供商非常關注的部分，因為這個區域的網路布局，布線拓撲結構，設備選型直接影響到整個網路運行的性能和成本以及項目的布線施工等。通常這個區域在網路規劃時是以接入點為中心，盡量將網路連接的距離設計到100米內，以減少網路中光纖互連的數量。重要原因是：傳統的銅線乙太網標准傳輸有一個最大距離限制100米。LRE技術可以大大延長這個距離，最大程度上取代小區或者商業區內之間互連的光纖，從而在大大降低了網路系統的投資和施工周期，為網路提供商提供性價比很高的組網方案。圖1主要說明了LRE在「最後一公里」接入中的應用。
據統計，95％的小區住宅樓之間或樓宇之間的網路互連距離在200米內，98％的樓道之間或樓宇單元之間的網路互連距離在100米之內。也就是說95％的小區住宅之間或樓宇之間的光纖可以由5類銅線替代。圖2是某小區接入的網路拓撲圖實例。圖中的連線和數字表示的是小區內住宅樓之間以及樓道之間的連接方式以及距離。紅線代表超過100米的5類線纜布線部分，採用4對5類雙絞線，白線代表100米內的5類線纜布線部分，採用25對5類雙絞線。綜合節約的設備成本，布線施工成本，整個項目節省總費用的30％以上。
LRE技術在樓宇寬頻接入中的應用
通常在商業樓宇中，乙太網接入是首選方式。對於比較高的樓宇，網路連接距離超過100米時，則必須使用Switch/Repeater等設備延長。LRE可以應用於類似布線的樓宇內，以減少多級Repeat，簡化網路結構，減少故障點，降低成本，同時大大提高網路的可靠性(圖3)。
LER技術在綜合接入中的應用
IAD (Integrated Access Device，綜合接入設備)在軟交換體系中位於接入層，其主要功能是將各種網路終端統一接入，能同時提供話音、數據、多媒體等多種業務的綜合接入功能。網路終端與IAD介面業務中，通常支持POTS，ISDN，DDN等窄帶業務和ADSL， VDSL，SHDSL，乙太網等寬頻業務。其中寬頻業務中乙太網接入雖然擁有介面通用，高寬頻等眾多優點，但由於銅線傳輸距離的約束，這種方式沒有像 xDSL等接入方式那樣廣泛地使用。LRE技術的採用，可以大大延長乙太網的傳輸距離，簡化網路結構，拓廣IAD接入的范圍。LRE技術可以極大地簡化綜合接入的布線，可以將PSTN等窄帶業務與乙太網寬頻業務捆綁在一起，只通過一根5類線，完成范圍在1000米范圍內的語音和10M帶寬的綜合接入。圖4 是LRE在綜合接入應用網路示意圖。
AT89C52的智能無線安防報警器
分類:技術文摘
http://www.yqxmcu.com/Html/mcukf/0621610505958549.htm
http://www.icwin.net/ShowArtitle.ASP?art_id=5080&cat_id=2
AT89C52的智能無線安防報警器
摘 要： 以MCS-51系列單片機AT89C52為核心，結合外圍無線編碼接收電路、DTMF發送接收電路、數字語音錄放電路、通話電路，以及其他的外圍輔助電路，構成了一款高性能的智能無線安防報警器。配合各種無線感測器，可實現防盜、防火等安防功能。它能智能地區分各種警情、自動數字語音電話報警，可接收遠端的電話遙控指令，有大功率繼電輸出口。
關鍵詞： 安防；報警器；AT89C52；電話報警
引言
現在安防報警系統越來越受到人們的重視，人們對報警器功能和性能方面的要求也越來越高。本文提出一種基於AT89C52的智能無線安防報警器：
·能與標準保安探頭進行無線連接，實現大范圍安防監控，並可隨意擴展。
·多防區功能。能夠區分各種警情，並能夠用語音播出警情類別。
·自動電話報警，向遠方用戶提供警情語音和現場聲響，並接收用戶指令進行相應操作。
·多功能自由切換，低誤報率，高可靠性。
·使用方便，有較高的性價比。
本報警器串接在外線和用戶的普通電話機中間。報警號碼的輸入、報警語音的錄制、無線感測器的錄入及其他主機參數的設定都是通過電話機完成，平時不影響電話機的工作，用戶用遙控器對主機進行布防或撤防。當主機接收到來自無線探頭發過來的編碼信號時，主機將編碼與原來存入的編碼進行對照，並查詢系統參數，決定是否報警和採取何種方式報警。它可以自動撥出用戶設置的報警電話，通過語音告知警情，用戶可監聽現場聲響，還可通過電話指令啟動警號和其他執行機構(如防煤氣泄露，可啟動排風扇)，並決定主機進入布防還是撤防狀態。用戶還可以主動從異地打電話到主機，對主機布防或撤防。
Ⅳ mysql行鎖等待異常
根據我之前接觸到的此類問題，大致可以分為以下幾種原因：
1. 程序中非資料庫交互操作導致事務掛起
將介面調用或者文件操作等這一類非資料庫交互操作嵌入在 SQL 事務代碼之中，那麼整個事務很有可能因此掛起（介面不通等待超時或是上傳下載大附件）。
2. 事務中包含性能較差的查詢 SQL
事務中存在慢查詢，導致同一個事務中的其他 DML 無法及時釋放佔用的行鎖，引起行鎖等待。
3. 單個事務中包含大量 SQL
通常是由於在事務代碼中加入 for 循環導致，雖然單個 SQL 運行很快，但是 SQL 數量一大，事務就會很慢。
4. 級聯更新 SQL 執行時間較久
這類 SQL 容易讓人產生錯覺，例如：update A set ... where ...in (select B) 這類級聯更新，不僅會佔用 A 表上的行鎖，也會佔用 B 表上的行鎖，當 SQL 執行較久時，很容易引起 B 表上的行鎖等待。
5. 磁碟問題導致的事務掛起
極少出現的情形，比如存儲突然離線，SQL 執行會卡在內核調用磁碟的步驟上，一直等待，事務無法提交。
綜上可以看出，如果事務長時間未提交，且事務中包含了 DML 操作，那麼就有可能產生行鎖等待，引起報錯。
Ⅳ centos 6.3 有Makefile 以及編譯器 就是不能make
編譯驅動需要內核源碼，你要先下載編譯並修改Makefiel 指定路徑
你的源碼可能在windows下打開過，重新下載在linux下解壓
Ⅵ MySQL 5.7中新增sys schema有什麼好處
性能優化利器:剖析MySQL 5.7新特徵 sys schema
導讀：很多團隊在評估合適的時機切換到 MySQL 5.7，本文是在高可用架構群的分享，介紹 MySQL 5.7 新的性能分析利器。
李春，現任科技 MySQL 負責人，高級 MySQL 資料庫專家，從事 MySQL 開發和運維工作 8 年。在擔任 MySQL 資料庫 leader 期間，主要負責應用架構的優化和部署，實現了阿里巴巴 3 億 產品 從 Oracle 小型機到 64 台 MySQL 的平滑遷移。專注於研究 MySQL 復制、高可用、分布式和運維自動化相關領域。在大規模、分布式 MySQL 集群管理、調優、快速定位和解決問題方面有豐富經驗。管理超過 1400 台 MySQL 伺服器，近 3000 個實例。完成 MySQL 自動裝機系統、MySQL 標准化文檔和操作手冊、MySQL 自動規范性檢查系統、MySQL 自動信息採集系統等標准化文檔和自動化運維工具。
sys schema 由來
Performance schema 引入
Oracle 早就有了 v$ 等一系列方便診斷資料庫性能的工具，MySQL DBA 只有羨慕嫉妒恨的份，但是 5.7 引入的 sys schema 緩解了這個問題，讓我們可以通過 sys schema 一窺 MySQL 性能損耗，診斷 MySQL 的各種問題。
說到診斷 MySQL 性能問題，不得不提在 MySQL 5.5 引入的 performance_schema，最開始引入時，MySQL 的 performance_schema 性能消耗巨大，隨著版本的更新和代碼優化，5.7 的 performance_schema 對 MySQL 伺服器額外的消耗越來越少，我們可以放心的打開 performance_shema 來收集 MySQL 資料庫的性能損耗。Tarique Saleem 同學測試了一下 sys schema 對 CPU 和 IO的額外消耗，基本在 1% - 3% 之間，有興趣的同學可以參考他的這篇 blog：
（CPU Bound, Sysbench Read Only Mode）
performance_schema 不僅由於他的性能消耗大著名，還由於其復雜難用而臭名昭著。5.7 上的 performance schema 已經有 87 張表了，每個表都是各種統計信息的羅列；另外，他的這些表和 information_schema 中的部分表也纏夾不清，讓大家用得很不習慣。
sys schema VS performance schema VS information schema
現在 MySQL 在 5.7 又新增了sys schema，它和 performance_schema 和 information schema 到底是什麼關系？
Information_schema 定位基本是 MySQL 元數據信息，比如：TABLES 記錄了 MySQL 有哪些表，COLUMNS 記錄了各個表有哪些列 。
performance_schema 記錄了 MySQL 實時底層性能消耗情況，比如：events_waits_current 記錄了 MySQL 各個線程當前在等待的 event。
雖然他們之間的這個定位區別並沒有那麼明顯：比如，Information_schema 的 innodb_locks 就記錄了 innodb 當前鎖的信息，它並不是 MySQL 的元數據信息。sys schema 最開始是 MarkLeith 同學為了方便讀取和診斷 MySQL 性能引入到 MySQL 的。所以 sys schema 定位應該是最清晰的：它包含一系列對象，這些對象能夠輔助 DBA 和開發人員了解 performance schema 和 information_schema 採集的數據。
sys schema 包含了什麼？
sys schema 包含一些對象，這些對象主要用於調優和故障分析。包括：
將 performance schema 和 information schema 中的數據用更容易理解的方式來總結歸納出來的「視圖」。
提供 performance schema 和 information schema 配置或者生成分析報告類似操作的「存儲過程」
sys schema 本身不採集和存儲什麼信息，它只是為程序或者用戶提供一個更加方便的診斷系統性能和排除故障的「介面」。也就是說，查詢 performance schema 和 information schema 配置和提供格式化服務的「存儲函數」。
避免用戶在 information schema 和 performance schema 中寫各種復雜的查詢來獲得到底誰鎖了誰，每個線程消耗的內存是多少 ( 視圖 memory_by_thread_by_current_bytes )，每個 SQL 執行了多少次，大致的執行時間是多少（ 視圖 statements_with_runtimes_in_95th_percentile ）等，這些 sys schema 都直接幫你寫好，你只需要直接查詢就好了。
編寫了一些現成的存儲過程，方便你：直接使用 diagnostics() 存儲過程創建用於診斷當前伺服器狀態的報告；使用 ps_trace_thread() 存儲過程創建對應線程的圖形化（ .dot類型 ）性能數據。
編寫了一些現成的存儲函數，方便你：直接使用 ps_thread_account() 存儲函數獲得發起這個線程的用戶，使用 ps_thread_trx_info() 來獲得某線程當前事務或者歷史執行過的語句（ JSON 格式返回 ）。
當然，你也可以在 sys schema 下增加自己用於診斷 MySQL 性能的「視圖」、「存儲過程」和「存儲函數」。
sys schema 舉例
怎麼利用 sys schema 來定位問題和診斷資料庫性能？這里簡單舉一個 innodb 行鎖的例子來說明。
模擬行鎖
拿一個實際的場景來說 sys schema 能夠輔助我們分析當前資料庫上哪個 session 被鎖住了，並且提供「清理」鎖的語句。我們模擬一個表的某一行被鎖住的情況，假設表創建語句如下：
CREATE TABLE `test2` (
`id` int(11) NOT NULL,
`name` varchar(16) DEFAULT NULL,
`age` int(11) DEFAULT NULL,
`sex` int(11) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
有一條數據如下：
mysql > select * from test2;
+----+---------+------+------+
| id | name | age | sex |
+----+---------+------+------+
| 2 | pickup1 | 1 | 1 |
+----+---------+------+------+
我們分別在 session 1 和 session 2 上同時操作這條數據，這樣的話必然對同一行記錄相互有鎖死的情況，然後我們通過 session 3 來查看 sys schema 裡面的 innodb_lock_waits，確定到底是誰鎖了誰，怎麼解鎖？操作步驟如下：
通過 sys.innodb_lock_waits 查看 innodb 鎖表情況
對應的在 session 3上查看到的記錄：
mysql > select * from sys.innodb_lock_waitsG
*************************** 1. row ***************************
wait_started: 2016-05-04 01:04:38
wait_age: 00:00:02
wait_age_secs: 2
locked_table: `test`.`test2`
locked_index: PRIMARY
locked_type: RECORD
waiting_trx_id: 5382
waiting_trx_started: 2016-05-04 00:24:21
waiting_trx_age: 00:40:19
waiting_trx_rows_locked: 4
waiting_trx_rows_modified: 0
waiting_pid: 3
waiting_query: update test2 set name='pickup3' where id=2
waiting_lock_id: 5382:31:3:3
waiting_lock_mode: X
blocking_trx_id: 5381
blocking_pid: 2
blocking_query: NULL
blocking_lock_id: 5381:31:3:3
blocking_lock_mode: X
blocking_trx_started: 2016-05-04 00:23:49
blocking_trx_age: 00:40:51
blocking_trx_rows_locked: 1
blocking_trx_rows_modified: 1
sql_kill_blocking_query: KILL QUERY 2
sql_kill_blocking_connection: KILL 2
這里我們可以看到 3 號線程（ waiting_pid: 3 ）在等待 2 號線程（ blocking_pid: 2 ）的 X 鎖（ blocking_lock_mode: X ），如果需要解鎖，需要殺掉 2 號線程（ sql_kill_blocking_connection: KILL 2 ）。
innodb_lock_waits 本質
其實 sys schema 的 innodb_lock_waits 只是 information schema 的視圖而已。
CREATE ALGORITHM = TEMPTABLE DEFINER = `mysql.sys`@`localhost` SQL SECURITY INVOKER VIEW `innodb_lock_waits` AS
SELECT
`r`.`trx_wait_started` AS `wait_started`,
TIMEDIFF(NOW(),
`r`.`trx_wait_started`) AS `wait_age`,
TIMESTAMPDIFF(
SECOND,
`r`.`trx_wait_started`,
NOW()) AS `wait_age_secs`,
`rl`.`lock_table` AS `locked_table`,
`rl`.`lock_index` AS `locked_index`,
`rl`.`lock_type` AS `locked_type`,
`r`.`trx_id` AS `waiting_trx_id`,
`r`.`trx_started` AS `waiting_trx_started`,
TIMEDIFF(NOW(),
`r`.`trx_started`) AS `waiting_trx_age`,
`r`.`trx_rows_locked` AS `waiting_trx_rows_locked`,
`r`.`trx_rows_modified` AS `waiting_trx_rows_modified`,
`r`.`trx_mysql_thread_id` AS `waiting_pid`,
`sys`.`format_statement`(`r`.`trx_query`) AS `waiting_query`,
`rl`.`lock_id` AS `waiting_lock_id`,
`rl`.`lock_mode` AS `waiting_lock_mode`,
`b`.`trx_id` AS `blocking_trx_id`,
`b`.`trx_mysql_thread_id` AS `blocking_pid`,
`sys`.`format_statement`(`b`.`trx_query`) AS `blocking_query`,
`bl`.`lock_id` AS `blocking_lock_id`,
`bl`.`lock_mode` AS `blocking_lock_mode`,
`b`.`trx_started` AS `blocking_trx_started`,
TIMEDIFF(NOW(),
`b`.`trx_started`) AS `blocking_trx_age`,
`b`.`trx_rows_locked` AS `blocking_trx_rows_locked`,
`b`.`trx_rows_modified` AS `blocking_trx_rows_modified`,
CONCAT(
'KILL QUERY ',
`b`.`trx_mysql_thread_id`
) AS `sql_kill_blocking_query`,
CONCAT('KILL ',
`b`.`trx_mysql_thread_id`) AS `sql_kill_blocking_connection`
FROM
(
(
(
(
`information_schema`.`innodb_lock_waits` `w`
JOIN
`information_schema`.`innodb_trx` `b` ON((`b`.`trx_id` = `w`.`blocking_trx_id`))
)
JOIN
`information_schema`.`innodb_trx` `r` ON(
(`r`.`trx_id` = `w`.`requesting_trx_id`)
)
)
JOIN
`information_schema`.`innodb_locks` `bl` ON(
(
`bl`.`lock_id` = `w`.`blocking_lock_id`
)
)
)
JOIN
`information_schema`.`innodb_locks` `rl` ON(
(
`rl`.`lock_id` = `w`.`requested_lock_id`
)
)
)
ORDER BY
`r`.`trx_wait_started`
innodb_lock_waits和x$innodb_lock_waits區別
有心的同學可能會注意到，sys schema 裡面有 innodb_lock_waits 和 x$innodb_lock_waits。其實 sys schema 的這些視圖大部分都成對出現，其中一個的名字除了 x$ 前綴以外跟另外一個是一模一樣的。例如，host_summmary_by_file_io 視圖分析匯總的是根據主機匯總的文件 IO 情況，並將延遲從皮秒（ picoseconds ）轉換成更加易讀值（ 帶單位 ）顯示出來：
mysql> SELECT * FROM host_summary_by_file_io;
+------------+-------+------------+
| host | ios | io_latency |
+------------+-------+------------+
| localhost | 67570 | 5.38 s |
| background | 3468 | 4.18 s |
+------------+-------+------------+
而 x$host_summary_by_file_io 視圖分析匯總的是同樣的數據，但是顯示的是未格式化過的皮秒（ picosecond ）延遲值
mysql> SELECT * FROM x$host_summary_by_file_io;
+------------+-------+---------------+
| host | ios | io_latency |
+------------+-------+---------------+
| localhost | 67574 | 5380678125144 |
| background | 3474 | 4758696829416 |
+------------+-------+---------------+
沒有 x$ 前綴的視圖是為了提供更加友好，對人更加易讀的輸出格式。帶 x$ 前綴的視圖顯示了數據原始格式，它方便其他工具基於這些數據進行自己的處理。需要了解非 x$ 和 x$ 視圖的不同點的進一步信息。
Q&A
提問：sys schema 只是在 performance_schema 和 information_schema 之上創建視圖和存儲過程？
李春：對，sys schema 主要針對的其實是 iperformance schema，有部分 information schema 的表也會整理到 sys schema 中統一展現。
提問：運行 KILL 2 殺掉 2 線程？blocking_lock_mode: X 的 X 什麼意思？
李春：blocking_lock_mode 的 X 是指 X 鎖，exclusive 鎖，排它鎖，跟它對應的是 S 鎖，共享鎖。kill 2 是殺掉 2 號線程，這樣可以將鎖釋放，讓被鎖的這個線程正常執行下去。
提問：可以放心的打開 performance_schema，為何不使用 performance_schema 再造一個 sys schema？
李春：performance schema 是 MySQL 採集資料庫性能的存儲空間。sys schema 其實只是對 performance schema 多個表 join 和整合。兩者的定位有所不同，如果直接放在 performance schema 中，分不清哪些是基表，哪些是視圖，會比較混淆。
提問：pt-query-digest 這些工具的有開始使用 sys schema 嗎？
李春：沒有，pt-query-digest 主要用於分析慢查和 tcpmp 的結果，跟 sys schema 的定位有部分重疊的地方，sys schema 會分析得更細，更內核，更偏底層一些，pt-query-digest 主要還是從慢查和 tcpmp 中抽取 SQL 來格式化展現。
提問：阿里這么多資料庫實例，使用什麼運維工具？分布式事務又是怎麼解決的呢？
李春：阿里內部有非常多的運維工具，dbfree，idb 等，用於資料庫資源池管理，資料庫脫敏，開發測試庫同步，資料庫訂正，表結構變更等。分布式事務主要通過業務上的修改去屏蔽掉，比如：電影買票並不是你選了座位和付款就必須在一個事務裡面，搶票，選座，付款分別是自己的子事務，系統耦合性比較弱，相互通知解決問題。
提問：Oracle 有 v$，MySQL 有 x$ ？兩個 $ 是完成相似功能的嗎？
李春：MySQL 的 x$ 可以說是仿照 Oracle 的 v$ 來做的，但是目前離 Oracle 的那麼強大的資料庫診斷功能還有一些距離。
提問：資料庫脫敏能否簡單介紹下實現方式？
李春：開發測試人員無法訪問線上資料庫，需要通過一個專門的 idb 來訪問，而 idb 系統每個欄位都有密級定義，滿足許可權的才能被訪問；這個系統頁控制了用戶是否可以訪問某個表，可以訪問數據表的行數，只有主管同意了，用戶才能訪問某個表的數據，並且加密數據是以*顯示的。
Ⅶ php新手學習路線是怎樣的
第一階段：基礎階段（基礎PHP程序員）
重點：把LNMP搞熟練（核心是安裝配置基本操作） 目標：能夠完成基本的LNMP系統安裝，簡單配置維護；能夠做基本的簡單系統的PHP開發；能夠在PHP中型系統中支持某個PHP功能模塊的開發。
時間：完成本階段的時間因人而異，有的成長快半年一年就過了，成長慢的兩三年也有。
Linux
基本命令、操作、啟動、基本服務配置（包括rpm安裝文件，各種服務配置等）；會寫簡單的shell腳本和awk/sed 腳本命令等。
Nginx
做到能夠安裝配置nginx+php，知道基本的nginx核心配置選項，知道 server/fastcgi_pass/access_log 等基礎配置，目標是能夠讓nginx+php_fpm順利工作。
MySQL
會自己搭建mysql，知道基本的mysql配置選項；知道innodb和myisam的區別，知道針對InnoDB和MyISAM兩個引擎的不同配置選項；知道基本的兩個引擎的差異和選擇上面的區別；能夠純手工編譯搭建一個MySQL資料庫並且配置好編碼等正常穩定運行；核心主旨是能夠搭建一個可運行的MySQL資料庫。
PHP
基本語法數組、字元串、資料庫、XML、Socket、GD/ImageMgk圖片處理等等；熟悉各種跟MySQL操作鏈接的api（mysql/mysqli/PDO)，知道各種編碼問題的解決；知道常規熟練使用的PHP框架（ThinkPHP、Zendframework、Yii、Yaf等）；了解基本MVC的運行機制和為什麼這么做，稍微知道不同的PHP框架之間的區別；能夠快速學習一個MVC框架。能夠知道開發工程中的文件目錄組織，有基本的良好的代碼結構和風格，能夠完成小系統的開發和中型系統中某個模塊的開發工作。
前端
如果條件時間允許，可以適當學習下 HTML/CSS/JS 等相關知識，知道什麼web標准，div+css的web/wap頁面模式，知道HTML5和HTML4的區別；了解一些基本的前端只是和JS框架（jQuery之類的）；了解一些基本的JavaScript編程知識；（本項不是必須項，如果有時間，稍微了解一下是可以的，不過不建議作為重點，除非個人有強烈興趣）。
系統設計
能夠完成小型系統的基本設計，包括簡單的資料庫設計，能夠完成基本的：瀏覽器 -> Nginx+PHP -> 資料庫 架構的設計開發工作；能夠支撐每天幾十萬到數百萬流量網站的開發維護工作；
第二階段：提高階段 （中級PHP程序員）
重點：提高針對LNMP的技能，能夠更全面的對LNMP有熟練的應用。 目標：能夠隨時隨地搭建好LNMP環境，快速完成常規配置；能夠追查解決大部分遇到的開發和線上環境的問題；能夠獨立承擔中型系統的構架和開發工作；能夠在大型系統中承擔某個中型模塊的開發工作。
1. Linux
在第一階段的基礎上面，能夠流暢的使用Shell腳本來完成很多自動化的工作；awk/sed/perl 也操作的不錯，能夠完成很多文本處理和數據統計等工作；基本能夠安裝大部分非特殊的Linux程序（包括各種庫、包、第三方依賴等等，比如MongoDB/Redis/Sphinx/Luncene/SVN之類的）；了解基本的Linux服務，知道如何查看Linux的性能指標數據，知道基本的Linux下面的問題跟蹤等。
2. Nginx
在第一階段的基礎上面，了解復雜一些的Nginx配置；包括 多核配置、events、proxy_pass，sendfile/tcp_*配置，知道超時等相關配置和性能影響；知道nginx除了web server，還能夠承擔代理伺服器、反向靜態伺服器等配置；知道基本的nginx配置調優；知道如何配置許可權、編譯一個nginx擴展到nginx；知道基本的nginx運行原理（master/worker機制，epoll），知道為什麼nginx性能比apache性能好等知識。
3. MySQL/MongoDB
在第一階段的基礎上面，在MySQL開發方面，掌握很多小技巧，包括常規SQL優化（group by/order by/rand優化等）；除了能夠搭建MySQL，還能夠冷熱備份MySQL數據，還知道影響innodb/myisam性能的配置選項（比如key_buffer/query_cache/sort_buffer/innodb_buffer_pool_size/innodb_flush_log_at_trx_commit等），也知道這些選項配置成為多少值合適；另外也了解一些特殊的配置選項，比如 知道如何搭建mysql主從同步的環境，知道各個binlog_format的區別；知道MySQL的性能追查，包括slow_log/explain等，還能夠知道基本的索引建立處理等知識；原理方面了解基本的MySQL的架構（Server+存儲引擎），知道基本的InnoDB/MyISAM索引存儲結構和不同（聚簇索引，B樹）；知道基本的InnoDB事務處理機制；了解大部分MySQL異常情況的處理方案（或者知道哪兒找到處理方案）。條件允許的情況，建議了解一下NoSQL的代表MongoDB資料庫，順便對比跟MySQL的差別，同事能夠在合適的應用場景安全謹慎的使用MongoDB，知道基本的PHP與MongoDB的結合開發。
4. Redis/Memcached
在大部分中型系統裡面一定會涉及到緩存處理，所以一定要了解基本的緩存；知道Memcached和Redis的異同和應用場景，能夠獨立安裝 Redis/Memcached，了解Memcahed的一些基本特性和限制，比如最大的value值，知道PHP跟他們的使用結合；Redis了解基本工作原理和使用，了解常規的數據類型，知道什麼場景應用什麼類型，了解Redis的事務等等。原理部分，能夠大概了解Memcached的內存結構（slab機制），redis就了解常用數據類型底層實現存儲結構（SDS/鏈表/SkipList/HashTable）等等，順便了解一下Redis的事務、RDB、AOF等機制更好。
5. PHP
除了第一階段的能力，安裝配置方面能夠隨意安裝PHP和各種第三方擴展的編譯安裝配置；了解php-fpm的大部分配置選項和含義（如max_requests/max_children/request_terminate_timeout之類的影響性能的配置），知道mod_php/fastcgi的區別；在PHP方面已經能夠熟練各種基礎技術，還包括各種深入些的PHP，包括對PHP面向對象的深入理解/SPL/語法層面的特殊特性比如反射之類的；在框架方面已經閱讀過最少一個以上常規PHP MVC框架的代碼了，知道基本PHP框架內部實現機制和設計思想；在PHP開發中已經能夠熟練使用常規的設計模式來應用開發（抽象工廠/單例/觀察者/命令鏈/策略/適配器 等模式）；建議開發自己的PHP MVC框架來充分讓開發自由化，讓自己深入理解MVC模式，也讓自己能夠在業務項目開發里快速升級；熟悉PHP的各種代碼優化方法，熟悉大部分PHP安全方面問題的解決處理；熟悉基本的PHP執行的機制原理（Zend引擎/擴展基本工作機制）。
6. C/C++
開始涉獵一定的C/C++語言，能夠寫基本的C/C++代碼，對基本的C/C++語法熟悉（指針、數組操作、字元串、常規標准API）和數據結構（鏈表、樹、哈希、隊列）有一定的熟悉下；對Linux下面的C語言開發有基本的了解概念，會簡單的makefile文件編寫，能夠使用簡單的GCC/GDB的程序編譯簡單調試工作；對基本的網路編程有大概了解。（本項是為了向更高層次打下基礎）。
7. 前端
在第一階段的基礎上面，熟悉基本的HTTP協議（協議代碼200/300/400/500，基本的HTTP交互頭）；條件允許，可以在深入寫出稍微優雅的HTML+CSS+JavaScript，或者能夠大致簡單使用某些前端框架（jQuery/YUI/ExtJS/RequireJS/BootStrap之類）；如果條件允許，可以深入學習JavaScript編程，比如閉包機制、DOM處理；再深入些可以讀讀jQuery源碼做深入學習。（本項不做重點學習，除非對前端有興趣）。
8. 系統設計
能夠設計大部分中型系統的網站架構、資料庫、基本PHP框架選型；性能測試排查處理等；能夠完成類似：瀏覽器 -> CDN(Squid) -> Nginx+PHP -> 緩存 -> 資料庫 結構網站的基本設計開發維護；能夠支撐每天數百萬到千萬流量基本網站的開發維護工作；
第三階段：高級階段 （高級PHP程序員）
重點：除了基本的LNMP程序，還能夠在某個方向或領域有深入學習。（縱深維度發展） 目標：除了能夠完成基本的PHP業務開發，還能夠解決大部分深入復雜的技術問題，並且可以獨立設計完成中大型的系統設計和開發工作；自己能夠獨立hold深入某個技術方向，在這塊比較專業。（比如在MySQL、Nginx、PHP、Redis等等任一方向深入研究）
1. Linux
除了第二階段的能力，在Linux下面除了常規的操作和性能監控跟蹤，還能夠使用很多高級復雜的命令完成工作（watch/tcpmp/starce/ldd/ar等)；在shell腳本方面，已經能夠編寫比較復雜的shell腳本（超過500行）來協助完成很多包括備份、自動化處理、監控等工作的shell；對awk/sed/perl 等應用已經如火純青，能夠隨意操作控制處理文本統計分析各種復雜格式的數據；對Linux內部機制有一些了解，對內核模塊載入，啟動錯誤處理等等有個基本的處理；同時對一些其他相關的東西也了解，比如NFS、磁碟管理等等；
2. Nginx
在第二階段的基礎上面，已經能夠把Nginx操作的很熟練，能夠對Nginx進行更深入的運維工作，比如監控、性能優化，復雜問題處理等等；看個人興趣，更多方面可以考慮側重在關於Nginx工作原理部分的深入學習，主要表現在閱讀源碼開始，比如具體的master/worker工作機制，Nginx內部的事件處理，內存管理等等；同時可以學習Nginx擴展的開發，可以定製一些自己私有的擴展；同時可以對Nginx+Lua有一定程度的了解，看看是否可以結合應用出更好模式；這個階段的要求是對Nginx原理的深入理解，可以考慮成為Nginx方向的深入專業者。
3. MySQL/MongoDB
在第二階段的基礎上面，在MySQL應用方面，除了之前的基本SQL優化，還能夠在完成一些復雜操作，比如大批量數據的導入導出，線上大批量數據的更改表結構或者增刪索引欄位等等高危操作；除了安裝配置，已經能夠處理更多復雜的MySQL的問題，比如各種問題的追查，主從同步延遲問題的解決、跨機房同步數據方案、MySQL高可用架構等都有涉及了解；對MySQL應用層面，對MySQL的核心關鍵技術比較熟悉，比如事務機制（隔離級別、鎖等）、對觸發器、分區等技術有一定了解和應用；對MySQL性能方面，有包括磁碟優化（SAS遷移到SSD）、伺服器優化（內存、伺服器本身配置）、除了二階段的其他核心性能優化選項（innodb_log_buffer_size/back_log/table_open_cache/thread_cache_size/innodb_lock_wait_timeout等）、連接池軟體選擇應用，對show *（show status/show profile）類的操作語句有深入了解，能夠完成大部分的性能問題追查；MySQL備份技術的深入熟悉，包括災備還原、對Binlog的深入理解，冷熱備份，多IDC備份等；在MySQL原理方面，有更多了解，比如對MySQL的工作機制開始閱讀部分源碼，比如對主從同步（復制）技術的源碼學習，或者對某個存儲引擎（MyISAM/Innodb/TokuDB）等等的源碼學習理解，如果條件允許，可以參考CSV引擎開發自己簡單的存儲引擎來保存一些數據，增強對MySQL的理解；在這個過程，如果自己有興趣，也可以考慮往DBA方向發展。MongoDB層面，可以考慮比如說在寫少讀多的情況開始在線上應用MongoDB，或者是做一些線上的數據分析處理的操作，具體場景可以按照工作來，不過核心是要更好的深入理解RMDBS和NoSQL的不同場景下面的應用，如果條件或者興趣允許，可以開始深入學習一下MongoDB的工作機制。
4. Redis/Memcached
在第二階段的基礎上面，能夠更深入的應用和學習。因為Memcached不是特別復雜，建議可以把源碼進行閱讀，特別是內存管理部分，方便深入理解；Redis部分，可以多做一些復雜的數據結構的應用（zset來做排行榜排序操作/事務處理用來保證原子性在秒殺類場景應用之類的使用操作）；多涉及aof等同步機制的學習應用，設計一個高可用的Redis應用架構和集群；建議可以深入的學習一下Redis的源碼，把在第二階段積累的知識都可以應用上，特別可以閱讀一下包括核心事件管理、內存管理、內部核心數據結構等充分學習了解一下。如果興趣允許，可以成為一個Redis方面非常專業的使用者。
5. PHP
作為基礎核心技能，我們在第二階段的基礎上面，需要有更深入的學習和應用。從基本代碼應用上面來說，能夠解決在PHP開發中遇到95%的問題，了解大部分PHP的技巧；對大部分的PHP框架能夠迅速在一天內上手使用，並且了解各個主流PHP框架的優缺點，能夠迅速方便項目開發中做技術選型；在配置方面，除了常規第二階段會的知識，會了解一些比較偏門的配置選項（php auto_prepend_file/auto_append_file），包括擴展中的一些復雜高級配置和原理（比如memcached擴展配置中的memcache.hash_strategy、apc擴展配置中的apc.mmap_file_mask/apc.slam_defense/apc.file_update_protection之類的）；對php的工作機制比較了解，包括php-fpm工作機制（比如php-fpm在不同配置機器下面開啟進程數量計算以及原理），對zend引擎有基本熟悉（vm/gc/stream處理），閱讀過基本的PHP內核源碼（或者閱讀過相關文章），對PHP內部機制的大部分核心數據結構（基礎類型/Array/Object）實現有了解，對於核心基礎結構（zval/hashtable/gc）有深入學習了解；能夠進行基本的PHP擴展開發，了解一些擴展開發的中高級知識（minit/rinit等），熟悉php跟apache/nginx不同的通信交互方式細節（mod_php/fastcgi）；除了開發PHP擴展，可以考慮學習開發Zend擴展，從更底層去了解PHP。
6. C/C++
在第二階段基礎上面，能夠在C/C++語言方面有更深入的學習了解，能夠完成中小型C/C++系統的開發工作；除了基本第二階段的基礎C/C++語法和數據結構，也能夠學習一些特殊數據結構（b-tree/rb-tree/skiplist/lsm-tree/trie-tree等）方便在特殊工作中需求；在系統編程方面，熟悉多進程、多線程編程；多進程情況下面了解大部分多進程之間的通信方式，能夠靈活選擇通信方式（共享內存/信號量/管道等）；多線程編程能夠良好的解決鎖沖突問題，並且能夠進行多線程程序的開發調試工作；同時對網路編程比較熟悉，了解多進程模型/多線程模型/非同步網路IO模型的差別和選型，熟悉不同非同步網路IO模型的原理和差異（select/poll/epoll/iocp等），並且熟悉常見的非同步框架（ACE/ICE/libev/libevent/libuv/Boost.ASIO等）和使用，如果閑暇也可以看看一些國產自己開發的庫（比如muo）；同時能夠設計好的高並發程序架構（leader-follow/master-worker等）；了解大部分C/C++後端Server開發中的問題（內存管理、日誌列印、高並發、前後端通信協議、服務監控），知道各個後端服務RPC通信問題（struct/http/thirft/protobuf等）；能夠更熟絡的使用GCC和GDB來開發編譯調試程序，在線上程序core掉後能夠迅速追查跟蹤解決問題；通用模塊開發方面，可以積累或者開發一些通用的工具或庫（比如非同步網路框架、日誌庫、內存池、線程池等），不過開發後是否應用要謹慎，省的埋坑去追bug。
7. 前端
深入了解HTTP協議（包括各個細致協議特殊協議代碼和背後原因，比如302靜態文件緩存了，502是nginx後面php掛了之類的）；除了之前的前端方面的各種框架應用整合能力，前端方面的學習如果有興趣可以更深入，表現形式是，可以自己開發一些類似jQuery的前端框架，或者開發一個富文本編輯器之類的比較瑣碎考驗JavaScript功力。
8. 其他領域語言學習
在基礎的PHP/C/C++語言方面有基本積累，建議在當前階段可以嘗試學習不同的編程語言，看個人興趣愛好，腳本類語言可以學學 Python/Ruby 之類的，函數式編程語言可以試試 Lisp/Haskell/Scala/Erlang 之類的，靜態語言可以試試 Java/Golang，數據統計分析可以了解了解R語言，如果想換個視角做後端業務，可以試試 Node.js還有前面提到的跟Nginx結合的Nginx_Lua等。學習不同的語言主要是提升自己的視野和解決問題手段的差異，比如會了解除了進程/線程，還有輕量級協程；比如在跨機器通信場景下面，Erlang的解決方案簡單的驚人；比如在不想選擇C/C++的情況下，還有類似高效的Erlang/Golang可用等等；主要是提升視野。
9. 其他專業方向學習
在本階段裡面，會除了基本的LNMP技能之外，會考慮一些其他領域知識的學習，這些都是可以的，看個人興趣和長期的目標方向。目前情況能夠選擇的領域比較多，比如、雲計算（分布式存儲、分布式計算、虛擬機等），機器學習（數據挖掘、模式識別等，應用到統計、個性化推薦），自然語言處理（中文分詞等），搜索引擎技術、圖形圖像、語音識別等等。除了這些高大上的，也有很多偏工程方面可以學習的地方，比如高性能系統、移動開發（Android/IOS）、計算機安全、嵌入式系統、硬體等方向。
10. 系統設計
系統設計在第二階段的基礎之上，能夠應用掌握的經驗技能，設計出比較復雜的中大型系統，能夠解決大部分線上的各種復雜系統的問題，完成類似 瀏覽器 -> CDN -> 負載均衡 ->接入層 -> Nginx+PHP -> 業務緩存 -> 資料庫 -> 各路復雜後端RPC交互（存儲後端、邏輯後端、反作弊後端、外部服務） -> 更多後端 醬紫的復雜業務；能夠支撐每天數千萬到數億流量網站的正常開發維護工作。
Ⅷ 優化mysql 多大內存 centos6
一、mysql的優化思路
mysql的優化分為兩方面：
1. 伺服器使用前的優化
2. 服務使用中的優化
二、mysql的基礎優化步驟
1. 硬體級優化
（1）. 最好mysql自己使用一台物理伺服器
（2）. 內存和CPU方面，根據需求給予mysql伺服器足夠大的內存和足夠多的CPU核數
(3). 避免使用Swap交換分區–交換時從硬碟讀取的它的速度很慢，有的DBA安裝系統時就不裝swap分區
（4）. 如果是mysql主庫，硬碟可以選用比較好的高速硬碟，系統用SSD固態硬碟，數據盤用sas替代sata硬碟，將操作系統和數據分區分開
（5）. mysql產生的日誌與資料庫也放到不同的磁碟分區上面
（6）. mysql資料庫硬碟格式化時，可以指定更小的硬碟塊
（7）. 關於做RAID方面，主庫盡量做成RAID10，既提高了數據的讀寫速度也提到了數據的安全性
（8). 伺服器雙線雙電，保障伺服器運行穩定，不會因為突然斷電影響業務和損壞磁碟數據
2. mysql資料庫設計優化
（1). 根據需求選擇正確的存儲引擎，比如說讀的特別猛就用MySAM,如果對事務性要求高就用InnoDB
(2). 設置合理的欄位類型和欄位長度,比如說你這個欄位就20多個欄位你設置成VARCHAR(255)就是對磁碟空間的浪費
（3）. 默認值盡可能的使用 NOT NULL，如果空值太多對mysql的查詢會有影響，尤其是在查詢語句編寫上面
（4）. 盡量少的使用VARCHAR，TEXT，BLOB這三個欄位
（5）. 添加適當索引(index) [四種: 普通索引、主鍵索引、唯一索引unique、全文索引]
（6）. 不要濫用索引，大表索引，小表不索引
（7）. 表的設計合理化(符合3NF)
3. mysql配置參數的優化
這里是mysql5.5版本的配置文件
vi my.cnf
[client]
port = 3306 #mysql客戶端連接時的默認埠
socket = /tmp/mysql.sock #與mysql伺服器本地通信所使用的socket文件路徑
default-character-set = utf8 #指定默認字元集為utf8
[mysql]
no-auto-rehash #auto-rehash是自動補全的意思，就像我們在linux命令行里輸入命令的時候，使用tab鍵的功能是一樣的，這里是默認的不自動補全
default-character-set = utf8 #指定默認字元集為utf8
[mysqld]
user = mysql
port = 3306
character-set-server = utf8 #設置伺服器端的字元編碼
socket = /tmp/mysql.sock
basedir = /application/mysql
datadir = /mysqldata
skip-locking #避免MySQL的外部鎖定，減少出錯幾率增強穩定性。
open_files_limit = 10240 #MySQL打開的文件描述符限制，默認最小1024;當open_files_limit沒有被配置的時候，比較max_connections*5和ulimit -n的值，哪個大用哪個，當open_file_limit被配置的時候，比較open_files_limit和max_connections*5的值，哪個大用哪個。
back_log = 500 #back_log參數的值指出在MySQL暫時停止響應新請求之前的短時間內多少個請求可 以被存在堆棧中。 如果系統在一個短時間內有很多連接，則需要增大該參數的值，該參數值指定到來的TCP/IP連接的偵聽隊列的大小。不同的操作系統在這個隊列大小上有它自 己的限制。 試圖設back_log高於你的操作系統的限制將是無效的。默認值為50。對於Linux系統推薦設置為小於512的整數。
max_connections = 800 #MySQL的最大連接數，如果伺服器的並發連接請求量比較大，建議調高此值，以增加並行連接數量，當然這建立在機器能支撐的情況下，因為如果連接數越多， 介於MySQL會為每個連接提供連接緩沖區，就會開銷越多的內存，所以要適當調整該值，不能盲目提高設值。可以過』conn%』通配符查看當前狀態的連接 數量，以定奪該值的大小。
max_connect_errors = 3000 #對於同一主機，如果有超出該參數值個數的中斷錯誤連接，則該主機將被禁止連接。如需對該主機進行解禁，執行：FLUSH HOST。
table_cache = 614 #物理內存越大,設置就越大.默認為2402,調到512-1024最佳
external-locking = FALSE #使用–skip-external-locking MySQL選項以避免外部鎖定。該選項默認開啟
max_allowed_packet =8M #設置最大包,限制server接受的數據包大小，避免超長SQL的執行有問題 默認值為16M，當MySQL客戶端或mysqld伺服器收到大於max_allowed_packet位元組的信息包時，將發出「信息包過大」錯誤，並關閉連接。對於某些客戶端，如果通信信息包過大，在執行查詢期間，可能會遇「丟失與MySQL伺服器的連接」錯誤。默認值16M。
sort_buffer_size = 6M #用於表間關聯緩存的大小，查詢排序時所能使用的緩沖區大小。注意：該參數對應的分配內存是每連接獨占，如果有100個連接，那麼實際分配的總共排序緩沖區大小為100 × 6 ＝ 600MB。所以，對於內存在4GB左右的伺服器推薦設置為6-8M。
join_buffer_size = 6M #聯合查詢操作所能使用的緩沖區大小，和sort_buffer_size一樣，該參數對應的分配內存也是每連接獨享。
thread_cache_size = 100 #伺服器線程緩存這個值表示可以重新利用保存在緩存中線程的數量,當斷開連接時如果緩存中還有空間,那麼客戶端的線程將被放到緩存中,如果線程重新被請求， 那麼請求將從緩存中讀取,如果緩存中是空的或者是新的請求，那麼這個線程將被重新創建,如果有很多新的線程，增加這個值可以改善系統性能.通過比較 Connections 和 Threads_created 狀態的變數，可以看到這個變數的作用
thread_concurrency = 8 #設置thread_concurrency的值的正確與否, 對mysql的性能影響很大, 在多個cpu(或多核)的情況下，錯誤設置了thread_concurrency的值, 會導致mysql不能充分利用多cpu(或多核), 出現同一時刻只能一個cpu(或核)在工作的情況。thread_concurrency應設為CPU核數的2倍. 比如有一個雙核的CPU, 那麼thread_concurrency的應該為4; 2個雙核的cpu, thread_concurrency的值應為8，屬重點優化參數
query_cache_size = 2M #指定MySQL查詢緩沖區的大小，在資料庫寫入量或是更新量也比較大的系統，該參數不適合分配過大。而且在高並發，寫入量大的系統，建系把該功能禁掉。
query_cache_limit = 1M #默認是4KB，設置值大對大數據查詢有好處，但如果你的查詢都是小數據查詢，就容易造成內存碎片和浪費
query_cache_min_res_unit = 2k #MySQL參數中query_cache_min_res_unit查詢緩存中的塊是以這個大小進行分配的，使用下面的公式計算查詢緩存的平均大小，根據計算結果設置這個變數，MySQL就會更有效地使用查詢緩存，緩存更多的查詢，減少內存的浪費。
default_table_type = InnoDB #默認表的引擎為InnoDB
thread_stack = 192K #限定用於每個資料庫線程的棧大小。默認設置足以滿足大多數應用transaction_isolation = READ-COMMITTED #設定默認的事務隔離級別.可用的級別如下:
READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ, SERIALIZABLE,1.READ UNCOMMITTED-讀未提交2.READ COMMITTE-讀已提交3.REPEATABLE READ -可重復讀4.SERIALIZABLE -串列
tmp_table_size = 246M #tmp_table_size 的默認大小是 32M。如果一張臨時表超出該大小，MySQL產生一個 The table tbl_name is full 形式的錯誤，如果你做很多高級 GROUP BY 查詢，增加 tmp_table_size 值。
max_heap_table_size = 246M #內存表，內存表不支持事務，內存表使用哈希散列索引把數據保存在內存中，因此具有極快的速度，適合緩存中小型資料庫，但是使用上受到一些限制
long_query_time = 1 #記錄時間超過1秒的查詢語句
log_long_format #
log-error = /logs/error.log #開啟mysql錯誤日誌，該選項指定mysqld保存錯誤日誌文件的位置
log-slow-queries = /logs/slow.log #慢查詢日誌文件路徑
pid-file = /pids/mysql.pid
log-bin = /binlog/mysql-bin #binlog日誌位置以及binlog的名稱
relay-log = /relaylog/relay-bin #relaylog日誌位置以名稱
binlog_cache_size = 1M #binlog_cache_size 就是滿足兩點的：一個事務，在沒有提交（uncommitted）的時候，產生的日誌，記錄到Cache中；等到事務提交（committed）需要提交的時候，則把日誌持久化到磁碟，默認是32K。
max_binlog_cache_size = 32M #binlog緩存最大使用的內存
max_binlog_size = 2M #一個binlog日誌的大小
expire_logs_days = 7 #保留7天的binlog
key_buffer_size = 124M #索引緩存大小: 它決定了資料庫索引處理的速度，尤其是索引讀的速度
read_buffer_size = 16M #MySql讀入緩沖區大小。對表進行順序掃描的請求將分配一個讀入緩沖區，MySql會為它分配一段內存緩沖區。read_buffer_size變數控制這一緩沖區的大小。如果對表的順序掃描請求非常頻繁，並且你認為頻繁掃描進行得太慢，可以通過增加該變數值以及內存緩沖區大小提高其性能
read_rnd_buffer_size = 2M #MySQL的隨機讀緩沖區大小。當按任意順序讀取行時(例如，按照排序順序)，將分配一個隨機讀緩存區。進行排序查詢時，MySQL會首先掃描一遍該緩沖，以避免磁碟搜索，提高查詢速度，如果需要排序大量數據，可適當調高該值。但MySQL會為每個客戶連接發放該緩沖空間，所以應盡量適當設置該值，以避免內存開銷過大
bulk_insert_buffer_size = 1M #批量插入數據緩存大小，可以有效提高插入效率，默認為8M
myisam_sort_buffer_size = 1M #MyISAM表發生變化時重新排序所需的緩沖
myisam_max_sort_file_size = 10G #MySQL重建索引時所允許的最大臨時文件的大小 (當 REPAIR, ALTER TABLE 或者 LOAD DATA INFILE). 如果文件大小比此值更大,索引會通過鍵值緩沖創建(更慢)
myisam_repair_threads = 1 #如果一個表擁有超過一個索引, MyISAM 可以通過並行排序使用超過一個線程去修復他們.這對於擁有多個CPU以及大量內存情況的用戶,是一個很好的選擇.
myisam_recover #自動檢查和修復沒有適當關閉的 MyISAM 表
lower_case_table_names = 1 #讓mysql不區分大小寫
skip-name-resolve #禁用DNS解析，連接速度會快很多。不過，這樣的話就不能在MySQL的授權表中使用主機名了而只能用ip格式。
#slave-skip-errors = 1032,1062 #這是選填項讓slave庫跳過哪些錯誤繼續同步
#replicate-ignore-db=mysql #選填，同步時候哪個資料庫不同步設置
server-id = 1
innodb_additional_mem_pool_size = 4M #InnoDB 存儲的數據目錄信息和其它內部數據結構的內存池大小。應用程序里的表越多，你需要在這里分配越多的內存，默認是2M
innodb_buffer_pool_size = 2048M #這對Innodb表來說非常重要。Innodb相比MyISAM表對緩沖更為敏感。MyISAM可以在默 認的 key_buffer_size 設置下運行的可以，然而Innodb在默認的 設置下卻跟蝸牛似的。由於Innodb把數據和索引都緩存起來，無需留給操作系統太多的內存，因此如果只需要用Innodb的話則可以設置它高達 70-80% 的可用內存。一些應用於 key_buffer 的規則有 — 如果你的數據量不大，並且不會暴增，那麼無需把 innodb_buffer_pool_size 設置的太大了
innodb_file_io_threads = 4 #文件IO的線程數，一般為 4
innodb_thread_concurrency = 8 #你的伺服器CPU有幾個就設置為幾,建議用默認一般為8
innodb_flush_log_at_trx_commit = 2 #默認為1，如果將此參數設置為1，將在每次提交事務後將日誌寫入磁碟。為提供性能，可以設置為0或2，但要承擔在發生故障時丟失數據的風險。設置為0表示事務日誌寫入日誌文件，而日誌文件每秒刷新到磁碟一次。設置為2表示事務日誌將在提交時寫入日誌，但日誌文件每次刷新到磁碟一次。
innodb_log_buffer_size = 2M #此參數確定些日誌文件所用的內存大小，以M為單位。緩沖區更大能提高性能，但意外的故障將會丟失數據.MySQL開發人員建議設置為1－8M之間
innodb_log_file_size = 4M #此參數確定數據日誌文件的大小，以M為單位，更大的設置可以提高性能，但也會增加恢復故障資料庫所需的時間
innodb_log_files_in_group = 3 #為提高性能，MySQL可以以循環方式將日誌文件寫到多個文件。推薦設置為3M
innodb_max_dirty_pages_pct = 90 #Buffer_Pool中Dirty_Page所佔的數量，直接影響InnoDB的關閉時間。參數 innodb_max_dirty_pages_pct可以直接控制了Dirty_Page在Buffer_Pool中所佔的比率，而且幸運的是 innodb_max_dirty_pages_pct是可以動態改變的。所以，在關閉InnoDB之前先調小，強制數據塊Flush一段時間，則能夠大大縮短MySQL關閉的時間。
innodb_lock_wait_timeout = 120 #InnoDB 有其內置的死鎖檢測機制，能導致未完成的事務回滾。但是，如果結合InnoDB使用MyISAM的lock tables 語句或第三方事務引擎,則InnoDB無法識別死鎖。為消除這種可能性，可以將innodb_lock_wait_timeout設置為一個整數值，指示 MySQL在允許其他事務修改那些最終受事務回滾的數據之前要等待多長時間(秒數)
innodb_file_per_table = 0 #獨享表空間（關閉）
[mysqlmp]
quick
max_allowed_packet = 16M
4. 架構優化
（1）. 前端用memcached，redis等緩存分擔資料庫壓力
（2）. 資料庫讀寫分離，負載均衡
（3）. 資料庫分庫分表
（4）. 存儲可採取分布式
5. 後期優化
主要是多觀察，後期就是維護工作了，觀察伺服器負載是需要添加硬體了，還是有語句有問題啊，還是參數要修改了。
6. 查詢優化（摘抄別人的）
63. 使用慢查詢日誌去發現慢查詢。
64. 使用執行計劃去判斷查詢是否正常運行。
65. 總是去測試你的查詢看看是否他們運行在最佳狀態下 –久而久之性能總會變化。
66. 避免在整個表上使用count(*),它可能鎖住整張表。
67. 使查詢保持一致以便後續相似的查詢可以使用查詢緩存。
68. 在適當的情形下使用GROUP BY而不是DISTINCT。
69. 在WHERE, GROUP BY和ORDER BY子句中使用有索引的列。
70. 保持索引簡單,不在多個索引中包含同一個列。
71. 有時候MySQL會使用錯誤的索引,對於這種情況使用USE INDEX。
72. 檢查使用SQL_MODE=STRICT的問題。
73. 對於記錄數小於5的索引欄位，在UNION的時候使用LIMIT不是是用OR.
74. 為了 避免在更新前SELECT，使用INSERT ON DUPLICATE KEY或者INSERT IGNORE ,不要用UPDATE去實現。
75. 不要使用 MAX,使用索引欄位和ORDER BY子句。
76. 避免使用ORDER BY RAND().
77。LIMIT M，N實際上可以減緩查詢在某些情況下，有節制地使用。
78。在WHERE子句中使用UNION代替子查詢。
79。對於UPDATES（更新），使用 SHARE MODE（共享模式），以防止獨占鎖。
80。在重新啟動的MySQL，記得來溫暖你的資料庫，以確保您的數據在內存和查詢速度快。
81。使用DROP TABLE，CREATE TABLE DELETE FROM從表中刪除所有數據。
82。最小化的數據在查詢你需要的數據，使用*消耗大量的時間。
83。考慮持久連接，而不是多個連接，以減少開銷。
84。基準查詢，包括使用伺服器上的負載，有時一個簡單的查詢可以影響其他查詢。
85。當負載增加您的伺服器上，使用SHOW PROCESSLIST查看慢的和有問題的查詢。
86。在開發環境中產生的鏡像數據中 測試的所有可疑的查詢。
Ⅸ 12星座最懼怕上什麼課
十二星座最怕什麼課
白羊座最怕歷史課
白羊座的人性格容易沖動，特別反感傳統古板的東西。所以他們對歷史課這種給人感覺沉悶乏味的學科最怕了，而且他們從來性格糙，自己和家裡人的生日都不一定記得，，更何況那些歷史人物的出生年月，或者死去日期呢？能記得一些朝代都很難了。
金牛座最怕英語課
金牛座的人羞怯表達出自己，天生就不太擅長語言，公開大膽的需要說出話的時候，金牛座的人會很為難，金牛座的人學習的時候只會默默的一個人鑽研，鑽研語法知識，但是口語卻很難。
雙子座最怕生物學
雙子座的人總是抱著天馬行空的幻想，但是生物是嚴謹的科學學科，如果總是在生物課里想像什麼，啦什麼都學不會的。不過雙子座倒是很熱衷於探討，只是這些探討可能和學習成績無關，所以雙子座的人還是最怕生物學了。
巨蟹座最怕化學課
巨蟹座的人藝術天賦更多，那些背理科公式的東西對他們來說很費勁，腦子轉不過來。那些元素周期表，也是著實讓巨蟹座頭疼。
獅子座最怕物理課
物理課是一門艱澀難懂的科學學科，學好物理的人一般來說都是很聰明的人，因為物理實在太復雜，太麻煩了，獅子座的大大咧咧的性格學不會這種需要嚴謹和細心的學科。
處女座最怕語文課
為什麼處女座最怕語文課呢？因為處女座的人太糾結，講究嚴謹，雖然語文成績不算差，但是遇上主觀題，還有作文那種，總是覺得哪裡不夠完美，喜歡修修改改，一來二去花費了很多時間。
天秤座最怕體育課
天秤座的人特別講究優雅，時刻都想保持自己高貴的形象，但是體育課這種科目，總是得把自己弄得風塵僕僕的，而且真的運動起來當然得出汗，那一不留神沒來得及換衣服就留了味道了。所以天秤座的人最怕體育課了。
天蠍座最怕音樂課
天蠍座的人怕音樂課倒不是因為五音不全，只是不喜歡在公眾面前那麼張揚。天蠍座的在舞台上也總是有特別的魅力，但是那有什麼辦法，天蠍座就是悶騷，不喜歡到處秀啊！
如果有他喜歡的人上音樂課到差不多。
射手座最怕數學課
射手座的人大大咧咧，自由散漫，要學嚴謹的數學，那可是 難上加難，他們壓根理解不了那些看似簡單公式里的復雜學問，射手座永遠也弄不懂裡面為什麼會出現那麼多變化，射手座上數學課總是像聽天書。一不小心走上神了就不知道說到哪了。
摩羯座最怕美術課
摩羯座的人一般來說比較中庸，他們總是不清楚那些藝術作品究竟在表達什麼，可能先天的天賦差了一點，所以上美術課總是那個被忽略的孩子，讓人總覺得他畫的東西沒意思。
水瓶座最怕歷史
其實水瓶座的人也是最怕歷史課的，他們覺得過去了的都過去了 ，那根本不重要，重要的是了解現在事物的內核，好好的過好現在就行了。歷史太經驗主義，不夠有邏輯性。
雙魚座最怕地理課
雙魚座的人最會的就是幻想，他們可能總是處於迷迷糊糊的狀態，平日里也總是路痴，所以地理對他們來說是最怕的科目了。
Ⅹ 如何編譯OpenWrt
Openwrt 官方正式的發行版是已編譯好了的映像文件（後綴名bin或trx、trx2），此映像文件可從Openwrt官方網站的下載頁面中輕松獲取到，連接地址為 OpenWrt官方網站。這些編譯好的映像文件是基於默認的配置設置，且只針對受支持的平台或設備的。因此，為什麼要打造一個自己的映像文件，理由有以下四點：
您想擁有一個個性化的配置OpenWrt（彰顯個性，在朋友圈子裡顯擺顯擺，開個玩笑）；
您想在實驗性的平台上測試OpenWrt；
您參與測試或參與開發OpenWrt的工作；
或者，最簡單的目的就是為了保持自己的Openwrt為最新版本；
若想實現上述目的，其實很簡單，按下述文字即可成功編譯出一個您的Openwrt來。
准備工作
在開始編譯Openwrt之前需要您做些准備工作；與其他編譯過程一樣，類似的編譯工具和編譯環境是必不可少的：
一個構建OpenWrt映像的系統平台，簡單說就是准備一個操作系統（比如Ubuntu、Debian等）；
確保安裝了所需的依賴關系庫， （在debian系統中就是安裝各種需要的軟體包）
OpenWrt源代碼副本
首先， 開機登陸到支持編譯Openwrt的操作系統（廢話了）。實體機或者虛擬機(Vmware 或者 Qemu)里的操作系統都行，這里推薦使用Linux系統。 bsd和mac osx系統也可以編，但不推薦，且未驗證是否可編譯成功。下文假定您使用的是Debian操作系統，使用 apt-get 來管理包. 替代的選擇是 Ubuntu (分支 Kubuntu, Xubuntu 等即可)。
第二步, 就是安裝所需要的各種軟體包, 包括編譯器,解壓工具,特定的庫等. 這些工作可以簡單的通過鍵入以下命令 (通常需要root 或者是 sudo 許可權)，以root許可權安裝下列軟體包(可能並不完整，會有提示，提示缺少即裝就可以了）:
32位(x86)請執行下列命令:
# apt-get install build-essential asciidoc binutils bzip2 gawk gettext \
git libncurses5-dev libz-dev patch unzip zlib1g-dev
64位(x86_64)請執行下列命令（多裝了哪些庫或軟體包呢？請您仔細看一看哦）:
# apt-get install build-essential asciidoc binutils bzip2 gawk gettext \
git libncurses5-dev libz-dev patch unzip zlib1g-dev ia32-libs \
lib32gcc1 libc6-dev-i386
參考 本列表中 所列的編譯環境所需要軟體包或庫。
某些依賴的為庫或軟體包也許操作系統中已經安裝過，此時apt-get會作出提示（提示您忽略或重新安裝的），別緊張，放輕鬆些，編譯Openwrt不會像編譯DD－WRT那樣難的（至少本人是體會到了編譯DD－WRT的難）。
最後下載一份完整的 Openwrt 源碼到編譯環境中。關於Openwrt的源代碼下載，途徑有二，一是通過 svn ，一是通過 git，建議使用 svn ，因為Openwrt主要以 svn 來維護Openwrt系統的版本。另外，請注意Openwrt中不同的分支版本，一個是用得較多的開發快照，俗稱 trunk，二是穩定版，俗稱 backfire。
安裝Subversion
若你想通過svn下載源代碼,你需安裝 Subversion。Subversion,或稱SVN, 是OpenWrt的project中用來控製版本的系統,它非常類似的 CVS的界面和使用條款。 執行下述命令即可安裝SVN，很容易的：
# apt-get install subversion
Subversion安裝完畢，通過SVN命令可獲取得到一份OpenWrt純凈源代碼。您還得創建一個目錄以便存放獲取得到的Openwrt源代碼，要獲取源代碼你還得輸入subversion命令來獲取 (svn里這種操作稱之為'check out') 。命令很簡單的，繼續看下去就能見到了，別著急，耐心點兒。
編譯流程
編譯專屬於您的設備的特定Openwrt固件以一下五個步驟：
通過Subversion命令獲得源代碼；
更新(或安裝) package feeds〔package feeds無法確切翻譯，待譯吧）；
創建一個默認配置以檢查編譯環境是否搭建好了 (假如需要的話)；
用Menuconfig來配置即將編譯生成的固件映像文件的配置項；
最後開始編譯固件；
下載源代碼
最後，下載一份完整的OpenWrt源代碼。你可選擇：
下載穩定發行版，或
下載開發版 (俗稱"trunk"版)。
使用發行版的源碼
截止本文時, Openwrt公開發行的穩定版為 OpenWrt 10.03 "backfire"。此版本是最穩定的，但也許不包括最新更新的補丁或最新編寫的出的新功能。
下述代碼即舉例說明了通過svn從brandkfire獲得backfire源代碼（此版本意思是從trunk分支的補丁也在backfire版本中了，即包含修復補丁）：
# mkdir OpenWrt/
# cd OpenWrt/
# svn co svn://svn.openwrt.org/openwrt/branches/backfire
註解: 上述svn命令將在當前目錄創建一個 OpenWrt/backfire/ 子目錄，此目錄包含此命令獲取到的源代碼。
您也可以通過下述命令，下載不含修復補丁的backfire的原版源碼：
# svn co svn://svn.openwrt.org/openwrt/tags/backfire_10.03
使用開發版源代碼
當前的開發版本分支(trunk)已包含最新的實驗補丁。此分支或許還突破了Openwrt原來所不支持的硬體設備的限制哦，驚喜的同時也有風險存在。因此，編譯trunk版，慎之～
# mkdir OpenWrt/
# cd OpenWrt/
# svn co svn://svn.openwrt.org/openwrt/trunk/
更多詳細資料詳見： https://dev.openwrt.org/wiki/GetSource.
跟進並更新源代碼
因Openwrt的源代碼隨時都會變動，故此命令將確保您所獲取得到的源碼的最新性。下述假設您用的是backfire版本的源碼：
## Here, backfire is the directory name of the current release branch you're tracking
# cd OpenWrt/backfire/
# svn up
'svn up' 命令用於更新SVN上更新了，但本地尚未更新的這部分源代碼（本人實踐證明此命令會將本地源碼與SVN上的源碼先比較，若SVN有更新才會下載更新的部分，很實用的一個命令）。如果未指定目標路徑，則此命令將更新當前目錄及當前目錄的子目錄內的源碼。
Feeds下載
Feeds即為包含到你的OpenWrt環境中的額外軟體包的索引之類的。（feed譯名很多，莫衷一是，至2008年底為止，還沒有一個十分通用而備受認可的中文譯名；所以此文當中我們用英文feed來稱呼）。 最主要的Feeds有以下三個：
'packages' - 路由的基本功能,
'LuCI' - OpenWrt默認的GUI（WEB管理界面）, 及
'Xwrt' - 其他的GUI。
一般情況，你至少需要含 'packages' 和 'LuCI'兩個Feeds。
下載完feeds之後， (為編譯OpenWrt的recipies額外的預定義包) 您可以檢查哪些feeds要包括在內。編輯在你的編譯環境的根目錄下的'feeds.conf.default'文件。
然後使用下列命令開始下載（註：可能你需要先運行cd trunk進入trunk目錄才能成功執行下列命令）：
# ./scripts/feeds update -a
在此之後，下載的軟體包需要安裝。亦即指的下邊的命令啦。若路過下邊的install命令則後續make menuconfig將無法成功執行！（註：可能你需要先運行cd trunk進入trunk目錄才能成功執行下列命令）：
# ./scripts/feeds install -a
只需編輯Feeds的配置文件或運行更新命令，即可很方便地更新或添加新的實驗性的packages到源碼中並編譯到OpenWrt固件去。
注意：請老壇友及舊的新聞組成員們注意了，這一步取代了創建符號鏈接symlinks的老辦法哦。
更新Feeds
諸如此類源碼,你得定期更新Feeds。 通過如上相同的命令:
# ./scripts/feeds update -a
# ./scripts/feeds install -a
注意:若你清楚地知道你不需添加新的packages到menuconfig中去，那麼你可在更新Feeds時跳過這一步。
生成配置
You may not have to make configration always after updating sources and feeds, but making it ensures that all packages from source and feeds are correctly included in your build configuration.
Defconfig
下一步是檢查編譯環境，若可進行編譯則生成默認配置：
# make defconfig
若defconfig回顯提示缺少軟體包或編譯庫等依賴，則按提示安裝所缺軟體包或庫等即可，不難的，細心點就行。
Menuconfig
menuconfig是一個基於文本的工具，它處理選擇的目標（需要還是不需要）、編譯生成軟體包（openwrt下是IPKG格式）以及內核選項（編譯成模塊還是內核）等等
# make menuconfig
在你離開並保存配置文件（默認都是.config）後，將自動配置依賴關系，讓你可以著手編譯更新的固件。
大眾可通過'menuconfig'這一簡單的圖形化的配置環境，非常輕松地編譯出專屬您本人的OpenWrt固件。
可以用'menuconfig'，以開發的意圖來編譯OpenWrt的固件，為自己（個人）創造一個結構簡單但是功能強大的環境。（上句實在難翻譯，只能意譯。並且也請大家都學習下編譯OP固件，讓以OP固件盈利的人丟掉那骯臟的飯碗！）
Menuconfig或多或少有些難以說明的地方，即使是最專業的配置，也可以尋求幫助並加以解決。 需要你指定何種目標平台，要包含的package軟體包和內核模塊等均需要你指定，配置標準的過程中會包括修改：
目標平台（即路由器何種架構，BCM呢還是AR均可選擇）
選擇要包含的package軟體包
構建系統設置
內核模塊
Target system is selected from the extensive list of supported platforms, with the numerous target profiles – ranging from specific devices to generic profiles, all depending on the particular device at hand. Package selection has the option of either 'selecting all package', which might be un-practical in certain situation, or relying on the default set of packages will be adequate or make an indivial selection. It is here needed to mention that some package combinations might break the build process, so it can take some experimentation before the expected result is reached. Added to this, the OpenWrt developers are themselves only maintaining a smaller set of packages – which includes all default packages – but, the feeds-script makes it very simple to handle a locally maintained set of packages and integrate them in the build-process.
假如你需要LuCI, 要到Administration 菜單里,在LuCI組件的子菜單下, 並選擇: luci-admin-core, luci-admin-full, and luci-admin-mini組件包。
假如你不需要PPP,你可到Network菜單下取消對它的選擇，以便編譯時不包含此組件。
Menuconfig用法: 確保這些組件包是以 '*'星號標記而不是 'M'標記。
如果你是以星號 '*'標記該組件包, 則該組件包將編譯進最終生成的OpenWrt固件中。
如果你僅以 'M'標記該組件包, 則該組件包將不會編譯進最終生成的OpenWrt固件中。
The final step before the process of compiling the intended image(s) is to exit 'menuconfig' – this also includes the option to save a specific configuration or load an already existing, and pre-configured, version.
Exit and save.
Source Mirrors
The 'Build system settings' include some efficient options for changing package locations which makes it easy to handle a local package set:
Local mirror for source packages
Download folder
In the case of the first option, you simply enter a full URL to the web or ftp server on which the package sources are hosted. Download folder would in the same way be the path to a local folder on the build system (or network). If you have a web/ftp-server hosting the tarballs, the OpenWrt build system will try this one before trying to download from the location(s) mentioned in the Makefiles . Similar if a local 'download folder', residing on the build system, has been specified. The 'Kernel moles' option is required if you need specific (non-standard) drivers and so forth – this would typically be things like moles for USB or particular network interface drivers etc.
編譯固件
萬事具備，只欠東風,通過下面簡單的make命令來編譯:
# make
在多核電腦中編譯
具有多核CPU處理器的電腦進行編譯，使用下述參數可令編譯過程加速。 常規用法為 <您cpu處理器的數目 + 1> – 例如使用3進程來編譯 (即雙核CPU), 命令及參數如下:
# make -j 3
後台編譯
若你在這個系統內編譯OpenWrt的同時還處理其他，可以讓閑置的I/O及CPU來在後台編譯固件 (雙核CPU):
# ionice -c 3 nice -n 20 make -j 2
編譯簡單的基本的軟體包
當你為OpenWrt開發或打包軟體包,編譯簡單的基本的軟體包可以很輕易地編譯該軟體包 (例如， 軟體包cups):
# make package/cups/compile V=99
一個在Feeds里的軟體包大約是這樣子的:
# make package/feeds/packages/ndyndns/compile V=99
編譯錯誤
如果因某種不知道的原因而編譯失敗,下面有種簡單的方法來得知編譯到底錯在哪裡了:
# make V=99 2>&1 |tee build.log |grep -i error
上述編譯命令意為：V99參數，將出錯信息保存在build.log，生成輸出完整詳細的副本（with stdout piped to stderr），只有在屏幕上顯示的錯誤。
舉例說明:
# ionice -c 3 nice -n 20 make -j 2 V=99 CONFIG_DEBUG_SECTION_MISMATCH=y 2>&1 \
|tee build.log |egrep -i '(warn|error)'
The above saves a full verbose of the build output (with stdout piped to stderr) in build.log and outputs only warnings and errors while building using only background resources on a al core CPU.
一鍵編譯
即使用腳本來編譯Openwrt固件。許多朋友編譯Openwrt是用的腳本來編譯的，詳見: https://forum.openwrt.org/viewtopic.php?id=28267
生成的固件在哪
編譯成功後所生成的固件文件位於bin目錄下，可用如下命令查看：
# cd bin/
# ls */
清理
編譯OpneWrt時你可能需要一個清潔干凈的編譯環境。 以下操作有利用編譯工作:
清潔
清潔trunk/ 目錄，在編譯過程中使用「make clean」命令即可。 此命令將刪除bin目錄和build_dir目錄下的所有文件及文件夾。
## See CAUTION below
# make clean