Little idiots (culture clash - “Dear, Dummies”), please find a tutorial on how to compile a command line client using the MySQL Driver for C++ with Visual Studio."Little idiot" may sound offending to native speakers. But it is spot on to describe my skills about compiling a Connector/C++ client on Windows. I need step-by-step instructions including screen shots. You will find them below.

The Internet Super Hero has started as a Little Idiot. Back in 1999 and ealier little idiots speaking german and trying to learn how to use MySQL loved Guido Stepkens MySQL introduction at http://www.little-idiot.de/mysql/mysql.html. Thank you for this early contribution to MySQL 3.23 and PHP 3, Guido! I still love the URL - little-idiot.de.

Contents

• …

These materials have been created in April 2009 and are outdated. No promises this still works.

Little idiots (culture clash - “Dear, Dummies”), please find a tutorial on how to compile a command line client using the MySQL Driver for C++ with Visual Studio."Little idiot" may sound offending to native speakers. But it is spot on to describe my skills about compiling a Connector/C++ client on Windows. I need step-by-step instructions including screen shots. You will find them below.

The Internet Super Hero has started as a Little Idiot. Back in 1999 and ealier little idiots speaking german and trying to learn how to use MySQL loved Guido Stepkens MySQL introduction at http://www.little-idiot.de/mysql/mysql.html. Thank you for this early contribution to MySQL 3.23 and PHP 3, Guido! I still love the URL - …

WARNING: nearly every word of this post is intentionally false. This is an April Fool’s joke.

There is so much misinformation out there about how MySQL works. If you’ve talked to someone from PostgreSQL, you’ve surely heard some of it: “MySQL doesn’t even have transactions,” for example. And this from a PostgreSQL user, who uses a database that doesn’t even run on Windows.

But even within the ranks of people who supposedly know MySQL’s workings, lots of people just get things dead wrong. I wanted to set the record straight here, so I thought I would give a little walk-through of how MySQL executes a query.

Let’s see it in action from start to finish.

SELECT SQL_NO_CACHE COUNT(col1) FROM users
WHERE userid IN(
   SELECT userid FROM othertbl
)
ORDER BY userid DESC;

The steps to execute this query are as …

It is all about one bug fix, one little feature, one step at a time.

Armin Schöffmann fixed a bug (Deadlock in mysql_real_query with shared memory connections, is what Armin calls it), Armin signed the Sun Contributor Agreement (24 March 2009), Vladislav Vaintroub and Davi Arnaut reviewed, committed and queued the patch to MySQL 5.0 bug team (26 and 27th of March, 2009).

That's a great example of open, contribution-based MySQL development with real results.

Thank you Armin!

Thank you Vlad!

Thank you Chad!

Thank you Davi!

Thank you ... the one whose name I've left out! (Feel free to leave a comment below.)

Just saw this story on Slashdot which made me think of this post from Marc Fleury.

The Slashdot story questions what/where is the official MySQL tree:

read more

Sounds a bit far fetched (pun intended ;-), but we're doing it. This is not inside of the MySQL server, but rather the overall application design. Let me run you through the logic...

Some key aspects to scaling are: not doing unnecessary queries, and caching what you can. Just a quick baseline. The fastest query is the one you don't do, or the one you've already done before - the latter being caching.

A simple yet brilliant example of this is the Youtube trick where a script reads the relay log, converting updates into appropriate selects and running them so that the InnoDB cache will have the blocks in memory when the slave SQL thread executes the actual update. Maatkit now has a tool for this, so it's publically available. It's not quite predictive, but it's a neat trick anyway that sometimes comes in handy. Search engines use similar tricks.

Extending on this, with certain applications you actually …

Sounds a bit far fetched (pun intended ;-), but we’re doing it. This is not inside of the MySQL server, but rather the overall application design. Let me run you through the logic…

Some key aspects to scaling are: not doing unnecessary queries, and caching what you can. Just a quick baseline. The fastest query is the one you don’t do, or the one you’ve already done before - the latter being caching.

A simple yet brilliant example of this is the Youtube trick where a script reads the relay log, converting updates into appropriate selects and running them so that the InnoDB cache will have the blocks in memory when the slave SQL thread executes the actual update. Maatkit now has a tool for this, so it’s publically available. It’s not quite predictive, but it’s a neat trick anyway that sometimes comes in handy. Search engines use similar tricks.

Extending on this, with certain applications you actually tell …

Assuming you have successfully compiled Drizzle, and you are ready to start for the first time, here are some beginner differences with those familiar with the current MySQL 5.1 GA version. Note: drizzle is actually an original fork of the 6.0.x codebase however the code looks very little like mysql anymore.

Getting started differences

The first default MySQL installation step scripts/install_mysql_db is gone, and there is no replacement. The ‘mysql’ schema no longer exists. Talking about schemas, ‘test’ is also gone by default.

While a bin/drizzled_safe exists to start drizzle, this presently doesn’t operate as expected. You should start drizzle with sbin/drizzled &

They still have an empty …