iMySQL | 老叶茶馆

闲话不多说了，相关文章请查看 PHP实现多服务器session共享之NFS共享 和 PHP实现多服务器session共享之memcache共享。
基于mysql的实现方式代码如下：

<?php
/* vim: set expandtab tabstop=4 shiftwidth=4 foldmethod=marker: */
//===========================================
// 程序：   mysql-Based Session Class
// 功能：   基于mysql存储的 Session 功能类
// 作者:    yejr
// 网站:    http://imysql.cn
// 时间:    2007-01-05
//===========================================

/**
 * 类名:    MySQL Session Class
 * 功能:    自主实现基于MySQL HEAP表存储的 Session 功能

  本文是 PHP实现多服务器session共享之NFS共享的延续，不过这次，我采用memcache来存储session了，memcache的安装请看这里： 搭建高效、可靠、稳定的WEB服务器 -- 二、) 安装MySQL、memcache。
接下来，再自定义一套session处理机制，关于session的实现方法我就不再多讲，直接贴程序了。

<?php
/* vim: set expandtab tabstop=4 shiftwidth=4 foldmethod=marker: */
//===========================================
// 程序：   Memcache-Based Session Class
// 功能：   基于Memcache存储的 Session 功能类
// 作者:    yejr

前言，Nio大侠提出了session多服务器共享的问题，原文请见PHP 实现多服务器共享 SESSION 数据。其中，有一种方法就是利用NFS来共享session，如果session量比较大并且所有的session文件都在同一个子目录下的话，那么可能会由此带来很严重的负载问题，甚至导致网站无法使用。本文就是对这个方案做一下详细的解说。
首先，修改 php.ini的 session.save_path 选项，大致如下：

session.save_path = "2;/tmp/php_sess"

意为把session存放在 "/tmp/php_sess" 目录下，并且分成 2 级子目录，每级子目录又分别有 16 个子目录。

一. 前言
近日由于需要,对discuz论坛(简称dz)进行优化,当然了,只是涉及到数据库的优化.
先说一下服务器及dz的数据量,2 * Intel(R) Xeon(TM) CPU 2.40GHz, 4GB mem, SCISC硬盘.
MySQL 版本为 4.0.23. 数据表情况:
cdb_attachments 2万
cdb_members 10万
cdb_posts 68万
cdb_threads 7万
二. 缓存优化
在 my.cnf 中添加/修改以下选项:

 #取消文件系统的外部锁
skip-locking
#不进行域名反解析,注意由此带来的权限/授权问题
skip-name-resolve
#索引缓存,根据内存大小而定,如果是独立的db服务器,可以设置高达80%的内存总量
key_buffer = 512M
#连接排队列表总数
back_log = 200

原文转自：http://www.example.net.cn/2006/06/mixijpsns.html
作者：于敦德 2006-6-27

mixi.jp：使用开源软件搭建的可扩展SNS网站

Mixi目前是日本排名第三的网站，全球排名42，主要提供SNS服务：日记，群组，站内消息，评论，相册等等，是日本最大的SNS网站。Mixi从2003年12月份开始开发，由现在它的CTO - Batara Kesuma一个人焊，焊了四个月，在2004年2月份开始上线运行。两个月后就注册了1w用户，日访问量60wPV。在随后的一年里，用户增长到了 21w，第二年，增长到了200w。到今年四月份已经增长到370w注册用户，并且还在以每天1.5w人的注册量增长。这些用户中70%是活跃用户（活跃用户：三天内至少登录一次的用户），平均每个用户每周在线时间为将近3个半小时。

由于需要，从4.0直接升级到5.0，查看了一下changelog，发现主要有以下变化：

一、从 4.0 到 4.1 的主要变化

• 如果在4.1.0到4.1.3版本的MySQL中创建了包含 TIMESTAMP 字段的 InnoDB
  表。则在升级到4.1.4及更高时需要重建表，因为存储格式发生变化了
• 字符串根据标准SQL来比较：比较之前不删除末尾的空格，以前用末尾空格扩展了比较短的字符串。现在的结果是
  'a' > 'a\t'，以前则不这样。可以用 mysqlcheck 来检查一下数据表
• TIMESTAMP 返回 'YYYY-MM-DD HH:MM:SS' 格式的字符串。在MySQL
  4.0中，可以增加选项 --new 来获得MySQL 4.1中这方面的特性
• 在MySQL
  4.1.1前，语句解析器不是那么严格，它在处理字符串转时间转换时会忽略第一个数字前的其他字符。在4.1.1之后，就比较严格了
• 返回结果是 DATE, DATETIME, 或 TIME 类型的函数的结果会被转换成时间型

二、再看从 4.1 到 5.0 的主要变化

• InnoDB 和 MyISAM 表中空格结尾的 TEXT 字段索引顺序改变了。因此需要运行
  "CHECK TABLE" 语句修复数据表，如果出现错误，就运行 "OPTIMIZE TABLE" 或 "REPAIR
  TABLE" 语句修复，甚至重新转储(用mysqldump)
• MySQL 5.0.15开始，如何处理 BINARY 字段中填充的值已经改变了。填充的值现在是
  0x00 而非空格了，并且在取值的时候不会去除末尾的空格
• 从MySQL 5.0.3开始，DECIMAL 的实现方式已经改变了，5.0对 DECIMAL
  的格式限制严格多了
• 在MySQL 5.0.3到5.0.5之间版本的 MyISAM 和 InnoDB 表中创建的 DECIMAL
  字段升级到5.0.6之后会发生崩溃
• 在以前，等待超时的锁会导致 InnoDB
  回滚当前全部事务，从5.0.13开始，就只回滚最近的SQL语句了
• 在4.1.13/5.0.8以前，DATETIME 的加0后就转换成 YYYYMMDDHHMMSS 格式，现在变成
  YYYYMMDDHHMMSS.000000 格式了
• 从5.0.3开始，DECIMAL 用更有效的格式来存储
• 5.0.3开始，在计算 DECIMAL 值和舍入精确值的时候采用精确数学
• 4.1中，FLOAT 或 DOUBLE 之间的比较碰巧没问题，但在5.0中可能就不行了
• 从5.0.3开始，VARCHAR 和 VARBINARY 字段中末尾的空格不再删除
• 增加了一个新的启动选项 innodb_table_locks，它导致 LOCK TABLE 时也可以请求
  InnoDB 表锁。这个选项默认打开，不过可能在 AUTOCOMMIT=1 和 LOCK TABLES
  应用中会导致死锁

原文摘录自: http://dev.mysql.com/tech-resources/articles/mysql-network-and-you.html,作者: Arjen Lentz(Community Relations Manager of MySQL AB)

End users

最终用户

If you are an end-user, you can use a GPL licensed server and will not require a commercial license to use MySQL. This applies even if you are an ISP or if you sell services on your e-commerce web site, since you are not distributing anything. If you are distributing anything, please see under the Developer heading below.

My favorite question during Interview for people to work as MySQL DBAs or be involved with MySQL Performance in some way is to ask them what should be tuned in MySQL Server straight after installation, assuming it was installed with default settings.

在面试MySQL DBA或者那些打算做MySQL性能优化的人时，我最喜欢问题是：MySQL服务器按照默认设置安装完之后，应该做哪些方面的调节呢？