It turns out, ‘NOT IN’ and ‘NULL’ can have an odd (to me) effect.

Say you are doing something like

SELECT a FROM table1
WHERE a NOT IN
(SELECT a FROM table2);

If there are any NULLs in the table2′s a column, you will never get any results from this query.
Here’s an example:

– first, here are the two tables I used:

mysql> select * from test1;
+——+
| a    |
+——+
|    1 |
|    2 |
|    3 |
|    4 |
|    5 |
|    6 |
+——+
6 rows in set (0.02 sec)

mysql> select * from test2;
+——+
| a    |
+——+
|    1 |
|    2 |
|    3 |
| NULL |
+——+
4 rows in set (0.00 sec)

mysql> select a from test1 where a not in (select a from test2);
Empty set (0.02 sec)

– personally, I expected to get 4,5,6.  For that, you can do the following:

mysql> select a from test1 where a not in (select a from test2 where a is NOT NULL);
+——+
| a    |
+——+
|    4 |
|    5 |
|    6 |
+——+
3 rows in set (0.00 sec)

Why is this?  It is actually to follow the SQL standards on NULL.  As mentioned at http://dev.mysql.com/doc/refman/5.1/en/comparison-operators.html ,

“To comply with the SQL standard, IN returns NULL not only if the expression on the left hand side is NULL, but also if no match is found in the list and one of the expressions in the list is NULL.”

Just as “1=NULL” is undefined rather than false, and “1<>NULL” is too, “1 in (null)” is also undefined (or null), and “1 NOT IN (null) is null”.

mysql> select 1 in (null);
+————-+
| 1 in (null) |
+————-+
|        NULL |
+————-+
1 row in set (0.00 sec)

mysql> select 1 not in (null);
+—————–+
| 1 not in (null) |
+—————–+
|            NULL |
+—————–+
1 row in set (0.00 sec)

To simplify the examples with tables above, we can do the following, and see similar results.

mysql> select 1 not in (2);
+————–+
| 1 not in (2) |
+————–+
| 1            |
+————–+
1 row in set (0.00 sec)

mysql> select 1 not in (2,null);
+——————-+
| 1 not in (2,null) |
+——————-+
| NULL              |
+——————-+
1 row in set (0.00 sec)

Personally, once I read the reasoning, it made sense to me, but initially I was surprised.  I thought I’d write about it, because it is common to do a “SELECT … WHERE NOT IN (SELECT …)”, as in the example above with table1 and table2, and the results might not be what you expect if you have any NULLs in your table.

I am super-excited to have signed on as a support engineer for MySQL! As you can read in my earlier posts, I had great experiences with MySQL support, so I’m really glad (and honored) to join the team.

Now I need to decide what direction I want to take this blog in. Maybe start a new blog with a different focus – I haven’t decided yet. Meanwhile, I have a lot of learning to do and have to get up-to-speed on things so I can be sure to do the support team proud! It’s going to be a little different from being a DBA, that’s for sure…

Anyway, I have a lot of ideas for future blog entries, but it might take a little while… Stay tuned.

Using the query profiler, you can get at wait times for a particular query, to help you tune it. There is the official documentation, and, even better, an article by Robin Schumacher that explains and gives examples.

From here it would probably be a “simple” matter to start collecting all this data system-wide, into a repository, to gather global information on wait-event times.   In the meantime, this is certainly a step in the right direction.

Good paper on the issues involved that gives tips, references tools and case studies, and has appendices that compare syntaxes, data types, etc. Wish I had found it earlier. Good to keep poking around from time to time, to find things like this.

(I’ve had a lot of questions along these lines, and have posted on all of each of these items somewhere, but thought it’d be more helpful to gather the points together into one place.)

MY TOP 2 “BEFORE YOU BEGIN” TOPICS

#1: storage engines. Before you do any big planning, if you don’t know what a “storage engine” is, find out!
I can’t think of a good analogy for what a storage engine is. The best I can come up with is, you know how with Oracle you choose your index types (btree? bitmap? etc)? In MySQL, you choose your table types (and with them, the index types). Your choice determines a lot. Each storage engine (table type) has various features and limitations. You need to know them. For instance, do you want ACID-compliant transactions or foreign-key constraints? You’ll most likely be using the InnoDB storage engine then. In which case, clustering is not supported – that would require the NDB storage engine (which, by the way, is an in-memory storage engine – ie, all your tables must fit into memory).
You can read more in my post on the subject, which includes further links for even more information.

#2: scale-out vs scale-up: plan your strategy (it’ll affect your schema and a lot more)
Plan your scaling strategy. Not only is it crucial to do, it might affect your schema design and much more! (Eg, if you “scale out”, you’ll need to plan your schema accordingly.)
You can read more in my post on that subject, which includes further linds for even more information.

Before you roll anything into production, you’ll need to read up on these topics (among others):

TWO VERY IMPORTANT THINGS THAT ARE DIFFERENT THAN YOU’RE USED TO

#1 backups
- read the documentation (on mysql.com) on mysqldump. It’s something like export, but you can use it with archived binary logs for point-in-time recovery, too.
- or use LVM if you have linux, to take snapshots
- or buy add-ons like MySQLHotCopy (?)
- or all of the above!
more notes with further links in this post.

#2 permissions
there are no roles; permissions are based on a userid and (if desired) the host or hosts they connect from. It’s a bit laborious, and you’ll want to read up on it and play with it. (I got snagged on it a few times; see this for an example.)

AND 5 OTHER THINGS I THINK YOU SHOULD KNOW ABOUT RIGHT OFF THE BAT

#1 collations – by default, if you compare strings, it’s not case sensitive (‘a’='A’). Read up on collations and character sets.
#2 autocommit is turned on by default. If you want to change this, read up on init_connect. Or see this post for more.
#3 the optimizer is not as developed/fine-tuned/complex be sure to test and QA and “analyze” your statements as much as possible. Use the slow query log to find longer-running queries and analyze them. Use “force index” in your select statements where needed (hopefully you know your data better than the optimizer).
#4: SQL_MODE. If you’re concerned about strict data integrity, you should read up on SQL_MODE. MySQL can insert “bad” data silently by default… (0′s for null dates, etc)
#5: isolation levels. If you’re going to use transactions (or even if you’re not), read up on isolation levels. This can affect locking, transactional integrity, etc. The default setting is not quite like Oracle’s.

where to get further info:
- download the software from mysql.com
- dev.mysql.com has the documentation, papers, etc
- planetmysql.com is a blog aggregator for MySQL-related blogs
- do lots of google’ing
- recommended books: Pro MySQL, MySQL 5.0 Certification Study Guide, MySQL Internals (and more…)

- buy MySQL support (it’s actually very good! Not at all like Oracle’s support. Best software support I’ve ever experienced by far, personally.)

In the latest Oracle Magazine, Tom Kyte and Ari Kaplan’s columns both tout one of 11g’s new features – the “server results cache” or “query result cache” (as the authors referred to it, respectively) . They both describe it as a “great new feature”. Neither happens to mention that MySQL has had this since version 4.0. It rankles me. It looks like there are a lot of truly “great new features” in 11g; let’s give credit for this one where it’s due.

I’m used to thinking of (Oracle) exports being one thing, and point-in-time recovery (using hot backups) another. Maybe there’s a way to do a “PITR” in Oracle using an export, rolling forward using timestamps rather than SCNs… Don’t know. I know that with MySQL you can do it.

Last night we had some user-generated data corruption on a production server. The database was relatively small (a few Gig), so, after stopping the database and restarting it with ––skip-networking, I imported it from the latest daily mysqldump. Although I didn’t use ––master-data for the mysqldump (we had some locking issues with that in the past) I knew the time that the mysqldump had been started.

I did a little investigation into the binary log files using mysqlbinlog

mysqlbinlog ––start-datetime=”2007-09-17 11:25:00″ ––stop-datetime=”2007-09-17 11:30:00″ binlog.000003 > my_tempfile

and found out the exact time I wanted to start rolling forward from. (I already knew when to stop rolling forward.) Then I ran it

mysql -p our_database < mysqlbinlog ––start-datetime=”2007-09-17 11:26:00 ––stop-datetime=”2007-09-17 20:45:00″

Checked things out, shut down mysql and restarted it normally, and we were once again off and running.

(Luckily for us, in this case I didn’t need to know an exact or down-to-the-second time to start rolling forward from. Activity was very light around the time of the mysqldump. Also, luckily, we didn’t need a starttime more precise than to-the-second. If we had needed to be more precise, I think I would have needed a mysqldump taken with the ––master-data option.)

My #1 wish for MySQL at this point would be that version 6 would be instrumented, so that we could tune using wait events, to identify actual wait times and what contributed to them by how much.

For now, I get recommendations like “Query Cache Has Sub-Optimal Hit Rate“, which is giving me flashbacks… (In our case, I don’t have to worry much about this in particular, and the advisors are good enough to let me know that I might “Evaluate whether the query cache is suitable for your application. If you have a high rate of INSERT / UPDATE / DELETE statements compared to SELECT statements, then there may be little benefit to enabling the query cache.“)

Anyway, it’s hit ratios all over again, making me pine for Oracle’s Automatic Workload Repository. Where I get recommendations about specific queries or indexes, and estimates for what the performance improvements might be if I change them, based on actual times spent doing operations. (And also, eg, how much time is spent waiting for things outside of the database, too, so you might avoid spending 80% of your time tuning something that will give your application an improvement of 2%.)

I think that, for now, the slow query log is my best friend. It gives me actual times spent doing which queries, and from there I can tune those queries. For the database itself, I’m back to comparing various ratios over time and trying to improve “bad” ones and seeing whether it makes a noticeable difference.

The MySQL family is gearing up for a new arrival. Falcon is still a baby in the belly, but it seems to already be getting more attention than its older and accomplished siblings (eg InnoDB). Maybe the proud mother-to-be has issues because every time she looks in InnoDB’s eyes she can’t stop thinking about the new stepmother, Oracle.

She seems to think this one will be the best baby ever, and has pinned high hopes on what it will grow up to become. Part of her excitement is because she is rightly taken with the brilliant father, Jim Starkey. If Dad could invent MVCC and BLOBs, what will baby Falcon grow up to accomplish under his care?

Hopefully the proud parents will have a keen eye open to shortcomings as well as strengths. Spare the rod
and spoil the child… Brilliant Dads don’t always make perfect fathers (to say the least). Time will tell, and we look forward to watching baby take its first steps and say its first words, and we hope it will live long and prosper. And that Mom will take an equally strong role as Dad in raising and forming the character of their new blessing. Based on the ultrasounds and other tests and measurements, there may be some issues that will need attention.

(Ultrasounds and commentary available from MySQL Performance Blog at InnoDB vs MyISAM vs Falcon benchmarks – part 1 and Falcon Storage Engine Design Review.)