In my previous post, I shared my finding that MySQL 5.6.7 does not make a cost-based choice between Materialization and IN-to-EXISTS strategies for subqueries.

It turns out I was wrong. As Guilhem Bichot has blogged here, he has implemented cost-based choice between Materialization and IN->EXISTS in MySQL 5.6.7. Igor Babaev also wrote about the topic, and covered the reasons I didn’t see the feature - it isn’t mentioned in the documentation, development process at Oracle is quite closed, and the feature didn’t work for a basic example that I have tried.

Let’s try to focus on the technical part of it. Looking at the source code, I see that

MySQL IN??? MySQL OR??? MySQL AND???
When I use one and when I use other?

we will use the city table to this tutorial:

+-------------+----------+------+-----+---------+----------------+
| Field       | Type     | Null | Key | Default | Extra          |
+-------------+----------+------+-----+---------+----------------+
| ID          | int(11)  | NO   | PRI | NULL    | auto_increment |
| Name        | char(35) | NO   |     |         |                |
| CountryCode | char(3)  | NO   | MUL |         |                |
| District    | char(20) | NO   |     |         |                |
| Population  | int(11)  | NO   |     | 0       |                |
+-------------+----------+------+-----+---------+----------------+

Let’s see a simple rule to clarify this:

AND – we use AND to add a new condition which will need to be

Hi guys, today let’s learn about a very useful option on mysql command line to recording all what happen in your mysql session, It’s the option –tee. Is very easy to use, you just need to add the –tee=/path/to/file

mysql -u root -p --tee=/tmp/log.mysql

It is all for today!
Enjoy!!!

MySQL 5.6 is now RC, I suppose this means that all features that were intended to be in release are pushed, so it’s time to take a look and see what’s going to be in MySQL 5.6 GA.

I decided to look at subquery optimizations and compare them to what we’ve got in MariaDB 5.3/5.5. In case you don’t know, subquery optimizations in MySQL 5.6 and MariaDB come from a common ancestor - MySQL 6.0 alpha, which was released in spring 2009 and then abandoned because there were too many unstable features pushed into it.

Then, both MariaDB team and Oracle salvaged subquery code out of the 6.0 mess, and worked to get it in shape for release. MariaDB released its results in GA quality in April 2012 as MariaDB 5.3, which was quickly followed by MariaDB 5.5.

Inside

Tuesday, September 25, 2012

MySQL and PHP are two key components in the open-source LAMP stack, and are widely used by web developers. One day you launched a website, and it gradually gained traction and now serves hundreds times more traffic than day one. As a PHP developer, have you ever looked back and adjusted the MySQL configurations accordingly to meet the most current website load? Have you ever wondered if there are secret tips you might have missed or common mistakes that you could have avoided but never thought of? If you answered yes to either question, this presentation is for you!

In this live webinar, PHP & MySQL experts Ulf Wendel and Johannes Schlüter will share the top 10 tips and mistakes for PHP developers. After a quick overview of lesser known but cool client and server features and plugins, and a recap

ConFoo is one of the most important web developer-oriented conferences. ConFoo 2013 will be held on February 25 through March 1 in Montreal, Canada.

We just opened call for papers and we are looking for the best PHP, Java, Ruby, DotNet,HTML5 experts who are willing to share their knowledge with the Canadian community. Candidates can submit proposals until September 23. Consult the call for papers page for details and to start submitting. That page also explains what expenses ConFoo can cover for speakers. You can also get advice on how to write proposals.

The call for papers is public, meaning that all proposals get published on the website for others to

Over the next few months, I am going to be writing about the MySQL Utilities, and I will be posting links to each individual blog on this page.

If you haven’t heard of the MySQL Utilities (from the introduction to MySQL Utilities page):

“MySQL Utilities is a package of utilities that are used for maintenance and administration of MySQL servers. These utilities encapsulate a set of primitive commands, and bundles them so they can be used to perform macro operations with a single command. MySQL Utilities may be installed via MySQL Workbench, or as a standalone package. The utilities are written in

I believe I’m nearly done with the SHOW EXPLAIN feature. The idea is that if you’ve got some long-running query $LONG_QUERY running in connection $LONG_QUERY_CONN, you should be able to create another connection, run SHOW EXPLAIN FOR $LONG_QUERY_CONN and see what query plan is being used to run the $LONG_QUERY.

How is this different from just running explain $LONG_QUERY? First, you don’t need to replicate the exact environment that $LONG_QUERY was run in: you don’t need to figure out what values it had for @@optimizer_switch and other settings, what were the contents of its temporary tables, if any, what did InnoDB told the optimizer about the table statistics, etc.

Another, indirect benefit is that we will now be able to produce query’s EXPLAIN at arbitrary point in time,

It’s been released. Use this with NIST::NVD 1.00.00 and you will be able to perform immediate look-ups of CVE and CWE data given a CPE URN. For instance:

cjac@foxtrot:/usr/src/git/f5/NIST-NVD-Store-SQLite3$ perl Makefile.PL ; make ; make test ; cjac@foxtrot:/usr/src/git/f5/NIST-NVD-Store-SQLite3$ perl -MNIST::NVD::Query -MData::Dumper -e '
$q = NIST::NVD::Query->new(store    => q{SQLite3},database => q{t/data/nvdcve-2.0.db});
$cve_list = $q->cve_for_cpe( cpe => q{cpe:/a:microsoft:ie:7.0.5730.11} );
print Data::Dumper::Dumper { cve_list => $cve_list, first_cvss => $q->cve( cve_id => $cve_list->[0] )->{q{vuln:cvss}} }
'
$VAR1 = {
          'cve_list' => [
                          'CVE-2002-2435',
                          'CVE-2010-5071'
                        ],
          'first_cvss' => {

I’ve been working on a data archival project over the last couple weeks and thought it would be interesting to discuss something a bit counter-intuitive. Absolutes are never true, but when getting rid of data, it’s usually more efficient to insert the data being kept into a new table rather than deleting the old data from the existing table.

Here is our example table from the IMDB database.

mysql> show create table title\G
*************************** 1. row ***************************
       Table: title
Create Table: CREATE TABLE `title` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `title` text NOT NULL,
  `imdb_index` varchar(12) DEFAULT NULL,
  `kind_id` int(11) NOT NULL,
  `production_year` int(11) DEFAULT NULL,
  `imdb_id` int(11) DEFAULT NULL,
  `phonetic_code`

A coworker came to me with a perplexing issue. He wanted to know why these two queries were not returning the same results:

mysql> SELECT COUNT(*) 
    -> FROM parent
    -> WHERE id NOT IN (SELECT parent_id FROM child);
+----------+
| count(*) |
+----------+
|        0 |
+----------+
1 row in set (7.84 sec)

mysql> SELECT COUNT(*)
    -> FROM parent p
    -> WHERE NOT EXISTS(SELECT 1 
    ->                  FROM child c
    ->                  WHERE p.id = c.parent_id);
+----------+
| count(*) |
+----------+
|     5575 |
+----------+
1 row in set (2.95 sec)

At first (and second, and third) glance these two queries look identical. It obviously is an exclusion join and because the MySQL optimizer is what it is, I