Apr 8, 2011

Mysql Temporary tables

he temporary tables could be very useful in some cases to keep temporary data. The most important thing that should be knows for temporary tables is that they will be deleted when the current client session terminates.
Temporary tables where added in MySQL version 3.23. If you use an older version of MySQL than 3.23 you can't use temporary tables, but you can use heap tables.
As stated earlier temporary tables will only last as long as the session is alive. If you run the code in a PHP script, the temporary table will be destroyed automatically when the script finishes executing. If you are connected to the MySQl database server through the MySQL client program, then the temporary table will exist until you close the client or manually destroy the table.

Example

Here is an example showing you usage of temporary table. Same code can be used in PHP scripts using mysql_query() function.
mysql> CREATE TEMPORARY TABLE SalesSummary (
    -> product_name VARCHAR(50) NOT NULL
    -> , total_sales DECIMAL(12,2) NOT NULL DEFAULT 0.00
    -> , avg_unit_price DECIMAL(7,2) NOT NULL DEFAULT 0.00
    -> , total_units_sold INT UNSIGNED NOT NULL DEFAULT 0
);
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO SalesSummary
    -> (product_name, total_sales, avg_unit_price, total_units_sold)
    -> VALUES
    -> ('cucumber', 100.25, 90, 2);

mysql> SELECT * FROM SalesSummary;
+--------------+-------------+----------------+------------------+
| product_name | total_sales | avg_unit_price | total_units_sold |
+--------------+-------------+----------------+------------------+
| cucumber     |      100.25 |          90.00 |                2 |
+--------------+-------------+----------------+------------------+
1 row in set (0.00 sec)
When you issue a SHOW TABLES command then your temporary table would not be listed out in the list. Now if you will log out of the MySQL session and then you will issue a SELECT command then you will find no data available in the database. Even your temporary table would also not exist.

Dropping Temporary Tables:

By default all the temporary tables are deleted by MySQL when your database connection gets terminated. Still you want to delete them in between then you do so by issuing DROP TABLE command.
Following is the example on dropping a temproary table.
mysql> CREATE TEMPORARY TABLE SalesSummary (
    -> product_name VARCHAR(50) NOT NULL
    -> , total_sales DECIMAL(12,2) NOT NULL DEFAULT 0.00
    -> , avg_unit_price DECIMAL(7,2) NOT NULL DEFAULT 0.00
    -> , total_units_sold INT UNSIGNED NOT NULL DEFAULT 0
);
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO SalesSummary
    -> (product_name, total_sales, avg_unit_price, total_units_sold)
    -> VALUES
    -> ('cucumber', 100.25, 90, 2);

mysql> SELECT * FROM SalesSummary;
+--------------+-------------+----------------+------------------+
| product_name | total_sales | avg_unit_price | total_units_sold |
+--------------+-------------+----------------+------------------+
| cucumber     |      100.25 |          90.00 |                2 |
+--------------+-------------+----------------+------------------+
1 row in set (0.00 sec)
mysql> DROP TABLE SalesSummary;
mysql>  SELECT * FROM SalesSummary;
ERROR 1146: Table 'TUTORIALS.SalesSummary' doesn't exist

MYSQL index

A database index is a data structure that improves the speed of operations in a table. Indexes can be created using one or more columns, providing the basis for both rapid random lookups and efficient ordering of access to records.
While creating index it should be considered that what are the columns which will be used to make SQL queries and create one or more indexes on those columns.
Practically, Indexes are also type of tables which keeps primary key or index field and a pointer to each record in to the actual table.
The users cannot see the indexes, they are just used to speed up queries and will be used by Database Search Engine to locate records very fast.
INSERT and UPDATE statements takes more time on tables having indexes where as SELECT statements become fast on those tables. The reason is that while doing insert or update, database need to inert or update index values as well.

Simple and Unique Index:

You can create a unique index on a table. A unique index means that two rows cannot have the same index value. Here is the syntax to create an Index on a table
CREATE UNIQUE INDEX index_name
ON table_name ( column1, column2,...);
You can use one or more columns to create an index. For example we can create an index on tutorials_tbl using tutorial_author
CREATE UNIQUE INDEX AUTHOR_INDEX
ON tutorials_tbl (tutorial_author)
You can creates a simple index on a table. Just omit UNIQUE keyword from the query to create simple index. Simple index allows duplicate values in a table.
If you want to index the values in a column in descending order, you can add the reserved word DESC after the column name:
mysql> CREATE UNIQUE INDEX AUTHOR_INDEX
ON tutorials_tbl (tutorial_author DESC)

ALTER command to add and drop INDEX:

There are four types of statements for adding indexes to a table:
  • ALTER TABLE tbl_name ADD PRIMARY KEY (column_list) : This statement adds a PRIMARY KEY, which means that indexed values must be unique and cannot be NULL.
  • ALTER TABLE tbl_name ADD UNIQUE index_name (column_list):This statement creates an index for which values must be unique (with the exception of NULL values, which may appear multiple times).
  • ALTER TABLE tbl_name ADD INDEX index_name (column_list):This adds an ordinary index in which any value may appear more than once.
  • ALTER TABLE tbl_name ADD FULLTEXT index_name (column_list):This creates a special FULLTEXT index that is used for text-searching purposes.
Here is the example to add index in an existing table.
mysql> ALTER TABLE testalter_tbl ADD INDEX (c);
You can drop any INDEX by using DROP clause along with ALTER command. Try out following example to drop above created index.
mysql> ALTER TABLE testalter_tbl DROP INDEX (c);
You can drop any INDEX by using DROP clause along with ALTER command. Try out following example to drop above created inde x.

ALTER Command to add and drop PRIMARY KEY:

You can add primary key as well in the same way. But make sure Primary Key works on columns which are NOT NULL.
Here is the example to add primary key in an existing table. This will make a column NOT NULL first and then add it as a primary key.
mysql> ALTER TABLE testalter_tbl MODIFY i INT NOT NULL;
mysql> ALTER TABLE testalter_tbl ADD PRIMARY KEY (i);
You can use ALTER command to drop a primary key as follows:
mysql> ALTER TABLE testalter_tbl DROP PRIMARY KEY;
To drop an index that is not a PRIMARY KEY, you must specify the index name.

Displaying INDEX Information:

You can use SHOW INDEX command to list out all the indexes associated with a table. Vertical-format output (specified by \G) often is useful with this statement, to avoid long line wraparound:
Try out following example:
mysql> SHOW INDEX FROM table_name\G
........

MYSQL ALTER command

MySQL ALTER command is very useful when you want to change a name of your table, any table field or if you want to add or delete an existing column in a table.
Lets begin with creation of a table called testalter_tbl
root@host# mysql -u root -p password;
Enter password:*******
mysql> use TUTORIALS;
Database changed
mysql> create table testalter_tbl
    -> (
    -> i INT,
    -> c CHAR(1)
    -> );
Query OK, 0 rows affected (0.05 sec)
mysql> SHOW COLUMNS FROM testalter_tbl;
+-------+---------+------+-----+---------+-------+
| Field | Type    | Null | Key | Default | Extra |
+-------+---------+------+-----+---------+-------+
| i     | int(11) | YES  |     | NULL    |       |
| c     | char(1) | YES  |     | NULL    |       |
+-------+---------+------+-----+---------+-------+
2 rows in set (0.00 sec)

Dropping, Adding, or Repositioning a Column:

Suppose you want to drop an existing column i from above MySQL table then you will use DROP clause along with ALTER command as follows
mysql> ALTER TABLE testalter_tbl  DROP i;
A DROP will not work if the column is the only one left in the table.
To add a column, use ADD and specify the column definition. The following statement restores the i column to testalter_tbl
mysql> ALTER TABLE testalter_tbl ADD i INT;
After issuing this statement, testalter will contain the same two columns that it had when you first created the table, but will not have quite the same structure. That's because new columns are added to the end of the table by default. So even though i originally was the first column in mytbl, now it is the last one:
mysql> SHOW COLUMNS FROM testalter_tbl;
+-------+---------+------+-----+---------+-------+
| Field | Type    | Null | Key | Default | Extra |
+-------+---------+------+-----+---------+-------+
| c     | char(1) | YES  |     | NULL    |       |
| i     | int(11) | YES  |     | NULL    |       |
+-------+---------+------+-----+---------+-------+
2 rows in set (0.00 sec)
To indicate that you want a column at a specific position within the table, either use FIRST to make it the first column, or AFTER col_name to indicate that the new column should be placed after col_name. Try the following ALTER TABLE statements, using SHOW COLUMNS after each one to see what effect each one has:
ALTER TABLE testalter_tbl DROP i;
ALTER TABLE testalter_tbl ADD i INT FIRST;
ALTER TABLE testalter_tbl DROP i;
ALTER TABLE testalter_tbl ADD i INT AFTER c;
The FIRST and AFTER specifiers work only with the ADD clause. This means that if you want to reposition an existing column within a table, you first must DROP it and then ADD it at the new position.

Changing a Column Definition or Name:

To change a column's definition, use MODIFY or CHANGE clause along with ALTER command. For example, to change column c from CHAR(1) to CHAR(10), do this:
mysql> ALTER TABLE testalter_tbl MODIFY c CHAR(10);
With CHANGE, the syntax is a bit different. After the CHANGE keyword, you name the column you want to change, then specify the new definition, which includes the new name. Try out following example:
mysql> ALTER TABLE testalter_tbl CHANGE i j BIGINT;
If you now use CHANGE to convert j from BIGINT back to INT without changing the column name, the statement be as expected:
mysql> ALTER TABLE testalter_tbl CHANGE j j INT;

The Effect of ALTER TABLE on Null and Default Value Attributes:

When you MODIFY or CHANGE a column, you can also specify whether or not the column can contain NULL values, and what its default value is. In fact, if you don't do this, MySQL automatically assigns values for these attributes.
Here is the example where NOT NULL column will have value 100 by default.
mysql> ALTER TABLE testalter_tbl 
    -> MODIFY j BIGINT NOT NULL DEFAULT 100;
If you don't use above command then MySQL will fill up NULL values in all the columns.

Changing a Column's Default Value:

You can change a default value for any column using ALTER command. Try out following example.
mysql> ALTER TABLE testalter_tbl ALTER i SET DEFAULT 1000;
mysql> SHOW COLUMNS FROM testalter_tbl;
+-------+---------+------+-----+---------+-------+
| Field | Type    | Null | Key | Default | Extra |
+-------+---------+------+-----+---------+-------+
| c     | char(1) | YES  |     | NULL    |       |
| i     | int(11) | YES  |     | 1000    |       |
+-------+---------+------+-----+---------+-------+
2 rows in set (0.00 sec)
You can remove default constraint from any column by using DROP clause along with ALTER command.
mysql> ALTER TABLE testalter_tbl ALTER i DROP DEFAULT;
mysql> SHOW COLUMNS FROM testalter_tbl;
+-------+---------+------+-----+---------+-------+
| Field | Type    | Null | Key | Default | Extra |
+-------+---------+------+-----+---------+-------+
| c     | char(1) | YES  |     | NULL    |       |
| i     | int(11) | YES  |     | NULL    |       |
+-------+---------+------+-----+---------+-------+
2 rows in set (0.00 sec)

Changing a Table Type:

You can use a table type by using TYPE clause alongwith ALTER command. Try out following example to change testalter_tbl to MYISAM table type.
To find out the current type of a table, use the SHOW TABLE STATUS statement.
mysql> ALTER TABLE testalter_tbl TYPE = MYISAM;
mysql>  SHOW TABLE STATUS LIKE 'testalter_tbl'\G
*************************** 1. row ****************
           Name: testalter_tbl
           Type: MyISAM
     Row_format: Fixed
           Rows: 0
 Avg_row_length: 0
    Data_length: 0
Max_data_length: 25769803775
   Index_length: 1024
      Data_free: 0
 Auto_increment: NULL
    Create_time: 2007-06-03 08:04:36
    Update_time: 2007-06-03 08:04:36
     Check_time: NULL
 Create_options:
        Comment:
1 row in set (0.00 sec)

Renaming a Table:

To rename a table, use the RENAME option of the ALTER TABLE statement. Try out following example to rename testalter_tbl to alter_tbl
mysql> ALTER TABLE testalter_tbl RENAME TO alter_tbl;
You can use ALTER command to create and drop INDEX on a MySQL file. We will see this feature in next chapter.

Mar 9, 2011

PHP number of days of a month

If you want to obtain number of days of a month, in PHP, you can use cal_days_in_month function:


int cal_days_in_month ( int $calendar , int $month , int $year )







So, here we have one example of usage of this function:


$num = cal_days_in_month(CAL_GREGORIAN, 8, 2003); // 31
    echo "There was $num days in August 2003";
?>

Feb 18, 2011

Introduction to MySQL 5.5

Here (http://dev.mysql.com/tech-resources/articles/introduction-to-mysql-55.html) you will find some notions about MySql 5.5. You'll be familiarized with the news from MySql 5.5:



What's New in MySQL 5.5

It's been a busy year for MySQL. Perhaps you've heard. Here are some recent improvements to the speed, scalability, and user-friendliness of the MySQL database and the InnoDB storage engine that we think deserve their own headlines. Now is a great time to beta test the 5.5 release and give feedback to the MySQL engineering team.

Improved Performance and Scalability

InnoDB Becomes Default Storage Engine
MySQL sometimes gets knocked about features such as as ACID-compliant transactions, foreign key support, and crash recovery. These features are strongest in the InnoDB storage engine, but MyISAM has always been the default, so new users could get the wrong impression. Starting in MySQL 5.5, InnoDB is the default storage engine, so that everyone can see this reliability and stability out of the box. As a bonus, the level of InnoDB in MySQL 5.5 is InnoDB 1.1, a rearchitected InnoDB with many performance and scalability features over and above the built-in InnoDB in 5.1 and before. (Since we are unifying the InnoDB within MySQL using the best and fastest technology, we are phasing out the Plugin versus Built-In distinction; MySQL 5.5 comes with the latest and greatest InnoDB 1.1.) Read more about the latest InnoDB enhancements below.
Better Metadata Locking within Transactions
If a table is referenced within a transaction, no other transaction can perform DDL such as DROP TABLE or ALTER TABLE until the first transaction commits. Previously, the lock was released at the end of a statement rather than the whole transaction. Read more about metadata locking within transactions.
Improved Performance and Scale on Win32 and Win64
If your company uses Windows by itself or in a mixed environment, you probably want to deploy MySQL databases on Windows. To make that a reality, the MySQL team has incorporated a number of Windows-specific features for speeding up and scaling up.
  • Windows API calls for much of the I/O done inside MySQL (a community contribution, hat tip to Jeremiah Gowdy).
  • Ability to build engines and other plugins as DLLs on Windows.
  • Network support for auto-detecting the MAC address (a community contribution, hat tip to Chris Runyan).
  • Much cleanup and simplifying of threading code.

Improved Availability

Semi-Synchronous Replication
This feature improves the reliability of failover, to avoid failing over to a slave that is missing some committed changes from the master. You can choose to have commits on the master node wait until at least one slave has logged the relevant events for the transaction. The semi-synchronous aspect is because the master does not wait for all the slaves to acknowledge, and there is a protocol to avoid the master waiting too long if the slaves fall behind. Read more about semisynchronous replication.
Replication Heartbeat
In replication, the heartbeat is a message sent at regular intervals from a master node to the slave nodes. You can configure the heartbeat period. If the message is not received, the slave knows that the master node has failed. You can now avoid the spurious relay log rotation when the master is idle, rely on an more precise failure detection mechanism, and have an accurate estimation for seconds behind master. (This is a different feature than Linux heartbeat, which is a similar health-checking system for cluster nodes.) To use this feature, you issue commands like:
STOP SLAVE;
CHANGE MASTER TO master_heartbeat_period= milliseconds;
START SLAVE;
SHOW STATUS like 'slave_heartbeat period'
SHOW STATUS like 'slave_received_heartbeats'

Improved Usability

SIGNAL/RESIGNAL
The SIGNAL and RESIGNAL statements allow you to implement familiar exception-handling logic in your stored procedures, stored functions, triggers, events, and database applications that call those things. SIGNAL passes execution back to an error handler, like THROW or RAISE statements in other languages. You can encode the error number, SQLSTATE value, and a message in a consistent way that can be interpreted by an error handler in the calling program. RESIGNAL lets you propagate the exception after doing some amount of error handling and cleanup yourself. With RESIGNAL, you can pass along the original error information or modify it. Read more about SIGNAL/RESIGNAL.
More Partitioning Options
With the new RANGE COLUMNS and LIST COLUMNS clauses of the CREATE TABLE statement, partitioning is now more flexible and also can optimize queries better. Instead of expressions, you specify the names of one or more columns. Both of these clauses let you partition based on DATE, DATETIME, or string values (such as CHAR or VARCHAR). Partition pruning can optimize queries on tables that use RANGE COLUMNS or LIST COLUMMS partitioning, and WHERE conditions that compare different columns and constants, such as
a = 10 AND b > 5
or
a < "2005-11-25" AND b = 10 AND c = 50
Read more about COLUMNS partitioning.
Performance Schema
The Performance Schema feature involves an optional schema, named performance_schema, with tables that you can query to see intimate details of low-level MySQL performance. You can get information about performance right at that moment, or various amounts of historical performance data. You can clear the data to reset the figures, filter and format the data using WHERE clauses, and generally interact with it using all sorts of SQL goodness. Performance Schema data now also includes details about the InnoDB storage engine. Read more about Performance Schema.

What's New in InnoDB

To make a long story short: it's all about performance and scalability! To those who enjoy trying all permutations of configuration settings, we apologize in advance for making so many of these improvements take no thought or effort at all.

Performance Improvements

At this year's MySQL Conference & Expo, you'll hear about the InnoDB Plugin 1.0.7, the first production-ready (GA) release of the InnoDB Plugin. Most of the enhancements listed here are from InnoDB 1.1, which is part of MySQL 5.5 and thus is still in beta. Download MySQL 5.5 and try them out.
Improved Recovery Performance
One of InnoDB's great strengths is its ability to reliably recover data after any type of crash that affects the database. But this cleanup and checking makes the next restart take longer. Well, cover up your sundial. Put away your hourglass. The enterprising InnoDB team has improved the algorithms involved in recovery by a huge amount -- in computer science terms, it's a better big-O number. Now you will need to keep your finger ready on the stopwatch to see how long recovery takes. This feature is available both in InnoDB 1.1 and the InnoDB Plugin 1.0.7. Read more about faster recovery.
Multiple Buffer Pool Instances
With today's buffer pools frequently in the multi-gigabyte range, pages are constantly being read and updated by different database threads. This enhancement removes the bottleneck that makes all the other threads wait when one thread is updating the buffer pool. All the structures normally associated with the buffer pool can now be multiplied, such as the mutex that protects it, the LRU information, and the flush list. You control how many buffer pool instances are used; the default is still 1. This feature works best with combined buffer pool sizes of several gigabytes, where each buffer pool instance can be a gigabyte or more. Read more about multiple buffer pool instances.
Multiple Rollback Segments
This feature is both a performance and a scalability improvement. By dividing the single rollback segment into multiple parts, InnoDB allows concurrent transactions to create undo data (from insert, update, and delete operations) without making each other wait. A happy consequence is that the old limit of 1023 simultaneous inserting / updating / deleting transactions is now much higher, for a total of approximately 128K concurrent writer transactions. This feature does not introduce any incompatibility in the InnoDB file format, and does not require using the newer Barracuda file format. However, the setup within the system tablespace only takes place when the system tablespace is created, so to take advantage of this feature, you must create a new instance (not just a new table or a new database) and import the data into it. Read more about multiple rollback segments.
Native Asynchronous I/O for Linux
This feature enables better concurrency of I/O requests on Linux systems. With asynchronous I/O, an I/O request can be sent off and the thread servicing the query does not need to wait for the I/O to complete; that aspect is delegated to the I/O helper threads. InnoDB already supported asynchronous I/O on Windows systems. On platforms other than Windows, InnoDB internally arranged its I/O calls as if they were asynchronous (leading to the term simulated asynchronous I/O), but behind the scenes the query thread really would block until the request finished. Now true asynchronous I/O support (called native asynchronous I/O so it won't be confused with references to asynchronous already in the source) is available on Linux as well as Windows. This feature requires the libaio userspace library to be installed on Linux. It comes with a configuration option innodb_use_native_aio that you can turn off in case of any startup problems related to the I/O subsystem. Read more about asynchronous I/O for Linux.
Extended Change Buffering: Now with Delete Buffering and Purge buffering
InnoDB uses indexes to make queries faster. Secondary indexes, those on columns other than the primary key, require work (meaning disk writes) to keep them up to date when those those columns are inserted, deleted, or updated. For example, if you run the command DELETE FROM t WHERE c1 = 'something';, and you have a secondary index on column c2, what's the rush to update that secondary index? Its contents might not be in the buffer pool, and maybe the index won't be read for a long time. InnoDB has had an optimization for a while now to delay disk writes for secondary index maintenance when the changes are due to inserts. This delay waits for the index contents to be read into the buffer pool for some other reason, such as a query, where the changes can be made quickly in memory and then flushed back to disk using the normal schedule for writing dirty blocks. When the changes in the buffer pool affect a group of sequential disk blocks, they can be flushed more efficiently than if the data was written piece by piece. Very clever! In InnoDB 1.1, this technique is extended to include the different kinds of writes caused by deletes (an initial delete marking operation, followed later by a purge operation that garbage-collects all the deleted records). This optimization is under your control through the innodb_change_buffering configuration option, which has a new default of all. (We call the optimization change buffering rather than the old name insert buffering; the actual memory structure is still called the insert buffer.) Read more about enhanced change buffering.

Scalability Improvements

The scalability improvements in InnoDB 1.1 revolve around better isolation of threads and mutex contention. These are performance-type improvements that really kick in when the database server is heavily loaded. (For those of you who are not yet experts on InnoDB performance, mutexes are in-memory structures that prevent different threads from interfering with each others' changes to important memory areas like the buffer pool.)
Improved Log Sys Mutex
Previously, a single mutex protected different memory areas related to the undo and logging information. In particular, this mutex blocked access to the buffer pool, while changes were being written there by DDL operations making changes to the data dictionary. Splitting the old log_sys mutex to create a separate log_flush_order mutex means that all of this internal processing can happen with less waiting and less blocking of other operations involving the buffer pool, without any configuration needed on your part. Read more about improved log sys mutex.
Separate Flush List Mutex
Along the same lines, operations involving the buffer pool and the flush list previously were protected by a single mutex, which could cause unnecessary delays. (The buffer pool mutex has historically been very hot, so any other operation that tied up the buffer pool was adding fuel to the fire.) Now the flush list has its own mutex, reducing contention with buffer pool operations and making InnoDB faster without any configuration needed on your part. Read more about separate flush list mutex.
Improved Purge Scheduling
The InnoDB purge operation is a type of garbage collection that runs periodically. Previously, the purge was part of the master thread, meaning that it could block some other database operations. Now, this operation can run in its own thread, allowing for more concurrency. You can control whether the purge operation is split into its own thread with the innodb_purge_threads configuration option, which can be set to 0 (the default) or 1 (for a single separate purge thread). This architectural change might not cause a big speedup with this single purge thread, but it lays the groundwork to tune other bottlenecks related to purge operations, so that in the future multiple purge threads could provide a bigger performance gain. The configuration option innodb_purge_batch_size can be set from 1 to 5000, with default of 20, although typical users should not need to change that setting. Read more about improved purge scheduling.

Better Instrumentation/Diagnostics

InnoDB Stats in Performance Schema
The Performance Schema has been part of MySQL 5.5 for a while now. InnoDB 1.1 is instrumented for the first time for Performance Schema monitoring, with statistics available for InnoDB-specific mutexes, rw-locks, threads, and I/O operations. The data is structured so that you can see everything, or filter to see just the InnoDB items. The information in the performance_schema tables lets you see how these items factor into overall database performance, which ones are the hottest under various workloads and system configurations, and trace issues back to the relevant file and line in the source code so you can really see what's happening behind the scenes. Read more about InnoDB integration with Performance Schema.