ubuntu 9.10下linuxqq经常挂掉的解决方案
ubuntu 9.10下linuxqq（官方的QQ，八百年不更新的那个了）
sudo vim /usr/bin/qq
增加
#!/bin/sh
export GDK_NATIVE_WINDOWS=true
cd /usr/share/tencent/qq/
经试验正确无误。。。linuxqq不再挂
Gearman for MySQL
Gearman是一个开源的分布式调度框架，支持多种语言。在分布式环境中，如何管理大量的服务器，将某些任务分发到大量的机器上调度执行，是一个比较大的挑战，Gearman为该类任务提供了一个不错的思路。在未来的MySQL集群环境中，Gearman这类工具应当大有用武之地，所以它也提供了MySQL UDF的支持。
一个Gearman请求的处理过程涉及三个角色：Client -> Job -> Worker。
Client：请求的发起者，可以是 C，PHP，Perl，MySQL UDF 等等。
Job：请求的调度者，用来负责协调把 Client 发出的请求转发给合适的 Worker。
Worker：请求的处理者，可以是 C，PHP，Perl 等等。
因为 Client，Worker 并不限制用一样的语言，所以有利于多语言多系统之间的集成。
SQL语句优化注意
1.尽量不要对列名进行函数处理.而是针对后面的值进行处理
例如where col1 = -5的效率比where -col1=5的效率要高
因为后面的条件对列值进行了计算.这样的条件下优化器无法使用索引
而是要针对所有值进行计算之后才能再比较
2.尽量使用和数剧列一样的值进行操作
如果col1是数值型
那么例如where col1 = 2和where col1= ‘2′
则前者效率更高
因为比较字符和数值型的时候
引擎需要把两者都转化成双精度然后进行比较
这样col1上的索引就失去作用了
3.减少函数的使用
例如where col1 >= ‘2009-10-26′ and col1 <= ‘2009-10-27′
和where datediff(day,col1,getdate())=0
后者因为用到函数处理.所以col1上的索引又无法使用了
4.尽量不要用OR
一般对于OR的条件
优化器一般会使用全表扫描
Oracle数据库视图与权限问题
前几天客户遇上这样一个问题，某个用户A将视图的Select给予另一个用户B，但是用户B查询这个视图时，仍然报错：ORA-01031: 权限不足。这是怎么一回事呢?下面来模拟一下这个过程：
有三个用户test1,test2,test3， 三个用户都具有DBA色色权限。
用TEST1用户创建一个表T1，并将其查询权限授予TEST2：
SQL> create table t1 as select * from all_objects;
表已创建。
SQL> grant select on t1 to test2;
授权成功。
SQL> create table t1 as select * from all_objects;
表已创建。
SQL> grant select on t1 to test2;
授权成功。 用TEST2用户创建一个视图，视图的基表是TEST1.T1，并将查询权限授予TEST3：
SQL> create view v_t1 as select * from test1.t1;
视图已建立。
SQL> grant select on v_t1 to test3;
授权成功。
SQL> create view v_t1 as select * from test1.t1;
视图已建立。
SQL> grant select on v_t1 to test3;
授权成功。 TEST3用户查询视图TEST2.V_T1：
SQL> select * from test2.v_t1 where rownum<1;
select * from test2.v_t1 where rownum<1
*
ERROR 位于第 1 行:
ORA-01031: 权限不足
SQL> select * from test2.v_t1 where rownum<1;
select * from test2.v_t1 where rownum<1
*
ERROR 位于第 1 行:
ORA-01031: 权限不足 可以看到报了权限不足的错误，就算这里TEST3用户有DBA权限。
这到底是怎么回事呢?
其实视图的权限，有两点需要引起注意：
1. 视图中，类似于定义者权限的存储过程，是屏蔽了角色权限的。比如如果TEST1没有显式地将T1表的Select权限给予TEST2，那么TEST2在创建视图V_T1时也会报ORA-01031错误，即使TEST2用户拥有DBA角色权限。
2.如果在用户A的视图中，引用了其他用户B的表，用户A将视图的访问权限给予用户C，那么就变相地将用户B的表的访问权限给予了用户C，因此，用户A必须有将用户B的表的访问权限转授用户C的权限，也就是用户B在授予A权限时，必须使用with grant option。
显然这里正是由于第2点的原因，导致用户TEST3不能访问视图。用户TEST1执行下面的操作，将解决这个问题：
SQL> grant select on t1 to test2 with grant option;
授权成功。
SQL> grant select on t1 to test2 with grant option;
授权成功。 对于视图的Update，Delete权限，同样是如此。
在测试时，有一个现象，有点意思。就是如果用户TEST2没有显式地把V_T1的Select权限授予TEST3，而TEST3在有Select ANY TABLE或DBA权限时，则查询这个视图时不会报权限不足的错误。由于有Select ANY TABLE权限的存在，所有的用户表都可以被访问。但是显式授予表的权限时，似乎表的权限有更高的优先级，并且没有跟系统权限和角色权限进行结合。或者版本不同，表现得不一样，在我的测试中，是Oracle 9.2.0.8 for Windows。
MySQL数据库的双向加密方式
如果你正在运行使用MySQL的Web应用程序，那么你把密码或者其他敏感信息保存在应用程序里的机会就很大。保护这些数据免受黑客或者窥探者的获取 是一个令人关注的重要问题，因为您既不能让未经授权的人员使用或者破坏应用程序，同时还要保证您的竞争优势。幸运的是，MySQL带有很多设计用来提供这 种类型安全的加密函数。本文概述了其中的一些函数，并说明了如何使用它们，以及它们能够提供的不同级别的安全。
双向加密
就让我们从最简单的加密开始：双向加密。在这里，一段数据通过一个密钥被加密，只能够由知道这个密钥的人来解密。MySQL有两个函数来支持这种类型的加密，分别叫做ENCODE()和DECODE()。下面是一个简单的实例：
mysql> Insert INTO users (username, password)
VALUES ('joe', ENCODE('guessme', 'abracadabra'));
Query OK, 1 row affected (0.14 sec)
其中，Joe的密码是guessme，它通过密钥abracadabra被加密。要注意的是，加密完的结果是一个二进制字符串，如下所示：
mysql> Select * FROM users Where username='joe';
+———-+———-+
| username | password |
+———-+———-+
| joe | ¡?i??!? |
+———-+———-+
1 row in set (0.02 sec)
abracadabra这个密钥对于恢复到原始的字符串至关重要。这个密钥必须被传递给DECODE()函数，以获得原始的、未加密的密码。下面就是它的使用方法：
mysql> Select DECODE(password, 'abracadabra')
FROM users Where username='joe';
+———————————+
| DECODE(password, 'abracadabra') |
+———————————+
| guessme |
+———————————+
1 row in set (0.00 sec)
应该很容易就看到它在Web应用程序里是如何运行的——在验证用户登录的时候，DECODE()会用网站专用的密钥解开保存在数据库里的密码，并和用户输入的内容进行对比。假设您把PHP用作自己的脚本语言，那么可以像下面这样进行查询：
undefined undefined
$query = "Select COUNT(*) FROM users Where
username='$inputUser' AND DECODE(password,
'abracadabra') = '$inputPass'";?>
注意：虽然ENCODE()和DECODE()这两个函数能够满足大多数的要求，但是有的时候您希望使用强度更高的加密手段。在这种情况下，您可以使用AES_ENCRYPT()和AES_DECRYPT()函数，它们的工作方式是相同的，但是加密强度更高。
InnoDB线程并发检查机制
InnoDB在接受MySQL线程调用时，有一个并发线程的检查机制，通过innodb_thread_concurrency参数进行控制。如果参数设置大于0，则表示检查机制开启，允许进入的线程数就是参数的值。等于0则禁用并发检查。
在新的MySQL线程调用Innodb接口前，Innodb会检查已经接受的请求线程数，如已经超过innodb_thread_concurrency设置的限制，则该请求线程会等待innodb_thread_sleep_delay微秒后尝试重新请求，如果第二次请求还是无法获得，则该线程会进入线程队列休眠。重试两次的机制是为了减少CPU的上下文切换的次数，以降低CPU消耗，这和Oracle中latch的spin机制是同样的道理。如果请求被Innodb接受，则会获得一个次数为innodb_concurrency_tickets(默认500次)的通行证，在次数用完之前，该线程重新请求时无须再进行前面所说innodb_thread_concurrency的检查。
上述检查逻辑在源码storage/innobase/srv/srv0srv.c(Innodb很多参数都可以在该文件中找到定义)的srv_conc_enter_innodb函数中，有兴趣的可以仔细阅读一下，代码比较浅显，不难理解。另外，如果是一个已经持有lock的线程，则通过调用srv_conc_force_enter_innodb函数可以无视该检查，这是为了避免线程长时间持有锁影响性能，且可能增加死锁的机率。除此之外，slave线程也是有无视检查直接通行的权限。
简单思考一下上述机制，可以得出一个初步的推论：在数据库并发请求较小的情况下，从性能上来说禁用检查机制应该是更好的，毕竟执行检查机制本身也需要加锁(Mutex)。当并发线程很高的情况下，则开启检查机制对性能更有利。至于具体innodb_thread_concurrency设置为多少，可能就需要在不同的条件下实际的做一下测试了，不同的硬件环境，不同的MySQL版本和Innodb版本，应该都会有一些区别。
源代码中对于innodb_thread_concurrency参数的注释如下：
/* The following controls how many threads we let inside InnoDB concurrently:
threads waiting for locks are not counted into the number because otherwise
we could get a deadlock. MySQL creates a thread for each user session, and
semaphore contention and convoy problems can occur withput this restriction.
Value 10 should be good if there are less than 4 processors + 4 disks in the
computer. Bigger computers need bigger values. Value 0 will disable the
concurrency check. */
ulong srv_thread_concurrency = 0;
因为检查机制需要Mutex保护(Mutex-based Model)，所以开启检查本身也有性能消耗，并且扩展性也会受到限制，在MySQL5.4版本中引入了一种新的机制（Timer-based Model），这里就不讨论了，实际上XtraDB存储引擎里已经包含Timer-based Model，通过参数innodb_thread_concurrency_timer_based可以开启，默认为OFF。在MySQL5.4的srv0srv.c的源代码中的注释中，可以看到Google和Percona的版权声明，看来MySQL5.4中吸引了很多第三方的改进代码，值得期待。
Sina App Engine
sina App Engine http://sae.sina.com.cn/
支持的服务:
PHP 5.3.0
Mysql 5.0.86
Memcache
Fetch URL
如果新浪免费，那么国内的虚拟主机商是不是将面临极大的挑战？因为无论是新浪还是国内的主机商，面临的政策风险都是一致的。
如果sina App Engine适当收费，国内主机商同样也会受到不小的冲击。
其实，我个人倒是希望sina App Engine能做大做强，毕竟在政策的影响下，google的所有服务基本上被防火墙攻击的支离破碎，国内用户谁还敢放心的使用？
现在国内的企业都在嚷嚷着云计算，不过一直都是雷声大，雨点小，多数仅仅是属于概念炒作而已。
无论如何sina App Engine总算是出来了，而且让人激动的是，支持的语言竟然是php+mysql。
云计算、sina App Engine，我们拭目以待。
