Showing posts with label mysql. Show all posts
Showing posts with label mysql. Show all posts

4/26/2009

Tunnelling MySQL Over SSH On ubuntu

Context:
1 local PC
2 Remote PC IP:192.168.0.51
3 My SSH user name on remote PC is edwin

1 build a tunnel By ssh:
I will open a local TCP port 3333 for tunnelling mysql; The syntax of SSH is


ssh -L LOCAL_PORT:hostname:REMOTE_PORT USER_NAME@SERVER_NAME or IP_ADDRESS.

or with sshpass

sshpass -p 'YOUR_PASSWD' ssh -o StrictHostKeyChecking=no -L 3333:localhost:3306 USERNAME@REMORT_HOST -p 22

We're using localhost as the hostname because we are directly accessing the remote mysql server through ssh. You could also use this technique to port-forward through one ssh server to another server.

#ssh -L 3333:localhost:3306 edwin@192.168.0.51

2 Connect reomote mysql using mysql command

#mysql -u root -p -h 127.0.0.1 -P 3333

4/24/2009

Common Select usage:Where condation of datatime format for query rows

There are 8 different ways for select rows form table by filed formated as datatime

1. where date like '2005-01-%'
2. where DATE_FORMAT(date,'%Y-%m')='2005-01'
3. where EXTRACT(YEAR_MONTH FROM date)='200501'
4. where YEAR(date)='2005' and MONTH(date)='1'
5. where substring(date,1,7)='2005-01'
6. where date between '2005-01-01' and '2005-01-31'
7. where date >= '2005-01-01' and date <= '2005-01-31'
8. where date IN('2005-01-01', '2005-01-02', '2005-01-03', '2005-01-04', '2005-01-05', '2005-01-06', '2005-01-07', '2005-01-08', '2005-01-09', '2005-01-10', '2005-01-11', '2005-01-12', '2005-01-13', '2005-01-14', '2005-01-15', '2005-01-16', '2005-01-17', '2005-01-18', '2005-01-19', '2005-01-20', '2005-01-21', '2005-01-22', '2005-01-23', '2005-01-24', '2005-01-25', '2005-01-26', '2005-01-27', '2005-01-28', '2005-01-29', '2005-01-30', '2005-01-31')

11/23/2008

解决Ubuntu8.04中mysql中文乱码

昨天刚在笔记本上安装Ubuntu 8.04,按照步骤安装了apt的mysql数据库,然后将现有的开发数据库导入(基于UTF-8),发现浏览的时候出现乱码现象,所以解决办法:
1 确认Mysql的编码
通过客户端进入mysql,执行


mysql>show variables like 'character%';
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | utf8 |
| character_set_filesystem | binary |
| character_set_results | utf8 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+

确认是编码问题
2 找到mysql的配置文件,修改/etc/mysql/my.cnf

sudo gedit /etc/mysql/my.cnf

在my.cnf文件中的[client]段和 [mysqld]段加上以下两行内容:

[client]
default-character-set=utf8
[mysqld]
default-character-set=utf8

3 需要重启mysql服务

sudo /etc/init.d/mysql restart


4 查看一下现在mysql的编码

sudo mysql -u root -p

mysql>show variables like 'character%';
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | utf8 |
| character_set_filesystem | binary |
| character_set_results | utf8|
| character_set_server | utf8 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+

5 编码正确,由于刚才导库的时候是基于错误编码的基础上作的,所以,会有编码的问题,因此,删除刚才导入的数据库,重新导入,打开页面,OK!

8/07/2008

graphical client for manage MySQL databases

GTK+ based client for MySQL wich allow to make querys and performs administrative jobs such as manage users, process, strucutres, data dumps and more.
sudo apt-get install gmysqlcc

5/03/2008

MySQL的日期和时间类型+PHP中的日期和时间函数

1. MySQL的日期时间列类型:
a. YEAR[(2|4)]

取值范围:2位为70-69 表示1970-2069; 4位表示1901-2155;
b. DATE
范围:1000-01-01到9999-12-31 格式为YYYY-MM-DD
c. TIME
范围:-838:59:59到838:59:59,格式为HH:MM:SS,注意其范围比想象的宽的多
d. DATETIME
范围:1000-01-01 00:00:00到9999-12-31 23:59:59,表示日期和时间,格式为

YYYY-MM-DD HH:MM:SS
e. TIMESTAMP[(M)]
范围:1970-01-01 00:00:00到2037年,表示格式有多种决定与M值:
TIMESTAMP: YYYYMMDDHHMMSS (14
位默认)
TIMESTAMP(14): YYYYMMDDHHMMSS
TIMESTAMP(12): YYMMDDHHMMSS
TIMESTAMP(10): YYMMDDHHMM
TIMESTAMP(8): YYYYMMDD
TIMESTAMP(6): YYMMDD
TIMESTAMP(4): YYMM
TIMESTAMP(2): YY

使用这些类型:

如果仅保存年使用YEAR;
保存日期使用DATE;
保存时间使用TIME;
保存日期和时间使用DATETIME或者TIMESTAMP;
另外注意取值范围

2. PHP中的日期和时间函数
1
)Unix timestamp:
Unix timestamp
表示把日期和时间转换为秒表示(距离Jan 01 1970时间差)

参考http://www.unixtimestamp.com/
尽管这种方法计算时间比较方便,但是面临最大值问题即若达到January 19, 2038将会出现32位溢出。
2
)PHP中常用的日期和时间函数:
尤其注意这里的timestamp为Unix timestamp即为距离1970-01-01的秒数。
和之前介绍的MySQL中的TIMESTAMP类型不同

(TIMESTAMP类型都是YYYYMMDDHHMMSS的格式,而不是秒数)
a. date(format,timestamp):
能够获取当前时间或者将已有的timestamp,转化为各种格式,通过format字符串可以定义格式。参考http://www.w3schools.com/php/func_date_date.asp
b। getdate(timestamp):
能够获取当前时间或者将已有的timestamp,转化为一个array
参考http://www.w3schools.com/php/func_date_getdate.asp
c। mktime(hour,minute,second,month,day,year,is_dst):
获取现在时间或者将已有的时间转换为timestamp
http://www.w3schools.com/php/func_date_mktime.asp
d. time()
获取当前时间的timestamp形式
http://www.w3schools.com/php/func_date_time.asp

3. 小结:
1
)
使用日期和时间,MySQL中的类型可以用DATETIME或者TIMESTAMP
两者分别保存为YYYY-MM-DD HH:MM:SS和YYYYMMDDHHMMSS等
在PHP方面可以使用date(format, timestamp)函数配合使用,因为date函数能够设置format将日期转化为符合DATETIME或者TIMESTAMP的格式保存起来。

2
)另一方面,在PHP中要习惯使用Unix timestamp这种形式的日期和时间,因为很方便计算,而且有很多函数方便使用。如果直接保存Unix timestamp可以将MySQL中的列类型定义为int(12)类似的整型就可以。

从PHP 5.1开始,date/time函数有一些变化,其中一项就是时区的设置。php.ini里增加了对应的设置date.timezone,同时也增加了相 应的函数date_default_timezone_get()和date-default_timezone_set()。如果不设置且未在程序中指 定,可能会在使用date/time函数时产生时差问题(win32平台就是)。
date_default_timezone_get()对时区的判定按照以下顺序:
  • 使用date_default_timezone_set() 函数所设置的值(如果有)

  • TZ 环境变量(如果非空)

  • php.ini中的date.timezone 选项(如果设置过)

  • "magical" 推测(如果操作系统支持)

  • 如果以上选项没有一个成功,则返回UTC

php.ini的选项如下:
[Date]
; Defines the default timezone used by the date functions
date.timezone = Asia/Shanghai
中国可以定义为Asia/Shanghai
或者使用date_default_timezone_set()函数
bool date_default_timezone_set ( string timezone_identifier )
timezone_identifier可以参看PHP文档的Appendix H, List of Supported Timezones。php.ini中的设置也使用这些值。

4/30/2008

PHP and MySQL, the future

Written by Brian Moon, dealnews.com developer, on June 27, 2006

The tried and true MySQL extension (mysql) has been around in PHP for years. Lately, there has been a lot of buzz in the PHP world about the new "MySQL Improved Extension" (mysqli) and "PHP Data Objects" (PDO). When I work on Phorum or for dealnews.com, I am always concerned with performance. So, I thought I would give these new methods a try.

What is mysqli?

The PHP manual says

"The mysqli extension allows you to access the functionality provided by MySQL 4.1 and above."

That is as far as it goes, so I am not sure which exact features we are talking about. Looking through the function list, I see things about charsets, encoding, transactions and prepared statements.

Another plus of mysqli is that it includes an OOP interface for those that like OOP. Although, after using it and looking at the docs, I was disappointed that all the work could not be done in 100% OOP. There are several times when calling a function is needed to check for errors and the like. At least, that is how the examples in the manual do it. Because I am not a big OOP user, I decided to stick with the procedural usage in my tests.

(After some hunting, I found an article at Zend.com that discusses mysqli and its improvements.)

What is PDO?

The PHP manual says

"The PHP Data Objects (PDO) extension defines a lightweight, consistent interface for accessing databases in PHP. Each database driver that implements the PDO interface can expose database-specific features as regular extension functions."

Like mysqli, it also supports prepared statements. However, for MySQL, it does not support everything that mysqli does. The most noticable is charset and encoding functionality. However, for new users (especially those from Perl, ASP, etc.) it is probably a good starting point.

Prepared statements

The MySQL manual says this about prepared statements:

"The MySQL client/server protocol provides for the use of prepared statements. This capability uses the MYSQL_STMT statement handler data structure returned by the mysql_stmt_init() initialization function. Prepared execution is an efficient way to execute a statement more than once. The statement is first parsed to prepare it for execution. Then it is executed one or more times at a later time, using the statement handle returned by the initialization function."

On of the big pluses I have heard about prepared statements is that it reduces (according to some, eliminates) sql injection flaws. So, I additionally tested mysqli and PDO in the select tests with prepared statements for that reason.

The nitty gritty tests

I ran two different tests. In all cases, test runs were made several times. The best score for each extension was recorded. No odd spikes or dips occured. Each extension stayed within a 10% range on each run.

Select Speed

The first was selecting 100 rows from a table. For this test, I used a query from the Phorum source code that is used on every message list page.

select
phorum_messages.author, phorum_messages.datestamp, phorum_messages.email,
phorum_messages.message_id, phorum_messages.meta, phorum_messages.moderator_post,
phorum_messages.modifystamp, phorum_messages.parent_id, phorum_messages.sort,
phorum_messages.status, phorum_messages.subject, phorum_messages.thread,
phorum_messages.thread_count, phorum_messages.user_id, phorum_messages.viewcount,
phorum_messages.closed
from
phorum_messages use index (list_page_float)
where
modifystamp > 0 and forum_id = 12 and status = 2 and parent_id = 0 and sort > 1
order by
modifystamp desc
limit 0, 100

Because I work on Phorum and other web based applications, I used openload to test these scripts on a web server. Timing a single query would not yield as much useful data. All the raw data is in raw_selects.txt.

extension req/s
------------------------
mysqli 164
mysql 162
PDO 88
mysqli (prepared) 86
PDO (prepared) 81

I was very disappointed in PDO's speed. However, I was glad to see that mysqli was basically identical to mysql (both varied from the 150's to 160's). It is clear however, that selects using prepared statements is not fast at all. I also found the syntax for using mysqli prepared statements to be cumbersome for selecting data.

Insert Speed

The next test was to insert 10,000 rows into a table. Each insert inserted a random amount of data into the char field and the text field. The table was built as such:

CREATE TABLE `testing_mysql` (
`id` int(10) unsigned NOT NULL auto_increment,
`char_field` varchar(255) NOT NULL default '',
`text_field` text NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM

MySQL supports what it calls extended inserts. Basically, you can send one query with multiple values sets. If you use --opt with mysqldump, it creates dumps using this format. I decided to test using this method and normal methods of all 3 extensions. In addition I tested prepared statements for mysqli and PDO.

extension time
--------------------------
pdo (extended) 18.17s
mysqli (extended) 18.40s
mysql (extended) 18.46s
pdo (prepared) 25.04s
mysqli (prepared) 36.93s
mysqli 50.43s
mysql 53.09s
pdo 59.96s

This was pretty much what I expected. Using extended inserts puts all the pressure on the database server. As you can see, using that format is fastest and basically the same across all extenstions. If you don't want to use that method, then prepared inserts are a sure fire winner. PDO was the clear winner for prepared inserts. That is a little surprising. I would expect the mysqli extension to be a port of the C mysql api and therefore have the least overhead.

Conclusion

Performance

For all around best performance, you could use either mysql or mysqli. Given they are so close, I consider mysqli the better choice. It gives you the best options on top of the speed. In my opinion, PDO is not for use on systems where mysql performance is a top goal. The only reason I would have for ever using PDO would be to write a generic ANSI-SQL standard driver for Phorum.

Features

For features, I think mysqli is the clear winner. With the ability to set connection preferences and other new features, it is much better than the mysql extension. The only thing PDO offers over mysqli is a more complete OOP interface. However, it lacks some database interaction features that mysqli includes.

Ease of use

The mysql extension is tried and true. There are lots of books and docs out there about it. That makes it still attractive for some. Also, many ISPs will not have support for mysqli or PDO as of yet. The good news is that the mysqli extension looks very much like the mysql extension. Just a little rework of parameters is all that is needed to convert from one to the other.

PDO is great for new users coming from ASP, Perl or any other language that has a single unified system for database interaction. It is simple to use and the syntax is quite logical and sensible. OOP users will love it as it is a 100% OOP interface. I would not recommend it however for power users or applications where high performance is a must.

Disappointment

One disappointment in this test was prepared statements and SQL injection. I had never used prepared statements or read the specifics about them. MySQL (and I assume other database servers) limits what can be prepared and substituted in a query. You can only substitute for things like the values of WHERE clauses and VALUES sets. Unfortunately, for PHP applications, that is not always the only places you need variable data. LIMIT clauses often change from one page to another for paging applications. This variable data must still be set using a string concatenation. So, while prepared statements can help with SQL injection, it is not the end all be all of SQL injection prevention. Its uses is really limited to insert statements only.

And the winner is...

In closing, I am very impressed with mysqli. It lived up to its name. It truly is mysql - improved. Its as fast as the mysql extension ever was and offers more features than PDO. Its OO interface is not as complete as PDO, but the bulk of interaction is there for those that like OOP. If you don't care about OOP, then there is absolutly no down side.