Of course, this is just a catchy title. As far as I know not all system tables can be converted to InnoDB yet (e.g. grant tables), which makes the header technically false. MyISAM is a very simple engine, and that has some inherent advantages (no transactional overhead, easier to “edit” manually, usually less space footprint on disk), but also some very ugly disadvantages: not crash safe, no foreign keys, only full-table locks, consistency problems, bugs in for large tables,… The 5.7.5 “Milestone 15” release, presented today at the Oracle Open World has an impressive list of changes, which I will need some time to digest, like an in-development ( …

The 5.7.5 DMR is now available, and we’ve made some changes to our build system in this one, so I wanted to spend some time discussing how you would now build MySQL.

When we released our April labs release, I wrote about building MySQL with Boost. Now that the first GIS work using Boost.Geometry has passed all the hurdles and landed in a development milestone release (DMR), it’s time to revisit the topic. From now on (5.7.5 and newer), MySQL needs Boost headers to compile. It’s not optional.

We got a few bug …

In my previous post about geo-spatial search in MySQL I described (along with other things) how to use geo-distance functions. In this post I will describe the geo-spatial distance functions in more details.

If you need to calculate an exact distance between 2 points on Earth in MySQL (very common for geo-enabled applications) you have at least 3 choices.

• Use stored function and implement haversine formula
• Use UDF (user defined function) for haversine (see below)
• In MySQL 5.6 you can use st_distance …

Setting up the Geospatial Data Abstraction Library
GDAL 1.10+ (by OS Geo) supports converting spatial data between various raster and vector (points, lines, polygons, etc.) based formats, along with supporting MySQL. MySQL and ESRI Shapefiles are generally the best supported combination today.

Version 1.10 of GDAL has big improvements over older versions, but most linux distros (EL6 has GDAL 1.7) only have packages for the older versions. I would recommend building the latest 1.11.0 release from source because the older source packages had a …

This post talks about how we make use of Boost.Geometry in MySQL to implement reliable and efficient GIS functionality, as well as changes to the GIS features in the lab release. Now that InnoDB is the default storage engine for MySQL, our user base is rapidly transitioning to InnoDB. One capability that they have been demanding is a performant and scalable GIS implementation. Along with adding R-tree index support to InnoDB, we also decided to replace the original GIS algorithms with a more powerful, reliable, effective and efficient geometric engine.

Summary
This post will offer a very simple demonstration of how you can use MySQL 5.7 for Spatial features within your applications. In order to demonstrate this, I’ll walk through how we can determine the 10 closest Thai restaurants to a particular location. For this example, we’ll be using the apartment that I lived in when I first started working at MySQL, back in 2003.

For more details on all of the new GIS related work that we’ve done in MySQL 5.7, please read through these blog posts from the developers:

• Why Boost.Geometry in MySQL?
• Making Use of …

In the newly released MySQL 5.7 labs release, users will find refactored GIS functions, as well as R-tree indexes in InnoDB. One notable change is that we have replaced a lot of the native code for geometry computation with an external library, namely Boost.Geometry. In fact, 5.7 will be the first MySQL release that depends on Boost. So why did we make such a move?

In recent years, we have seen a tremendous growth in location based services, and consequently GIS has become a strategically important area for MySQL. Our existing customers require more GIS features, and we believe this is a growing market opportunity.

Up to MySQL 5.6, GIS support in MySQL has been very limited, and the geometry algorithms implemented in MySQL were overly simple and couldn’t handle many corner cases. …

With MySQL 5.7.4 LAB release, InnoDB now supports “Spatial Index” on geometry data.

Before this new feature, InnoDB stores geometry data as BLOB data, and only prefix index can be created on the spatial data. It is very inefficient when comes to spatial search, especially when it comes to complex geometry data. In most cases, table scan are the only way to get the result. This all changed with InnoDB spatial index, which is implemented as R-tree, any spatial search becomes far more efficient.

InnoDB spatial index can be used with all existing syntax that has been developed for MyISAM spatial index. In addition, InnoDB spatial index supports full transaction properties, as well as isolation levels. It employs predicate lock to prevent phantom scenario.

In InnoDB spatial index, only the object’s Minimum Bounding Box is included in the index, making the index entry size small and packed, even with large, complex …

We have a new April labs release that you can download from labs.mysql.com. There are more labs releases. Please try them all, but for now let’s focus on the one called “MySQL GIS, InnoDB R-tree, Parser Refactoring”.

The release contains InnoDB R-trees, the first step of our new GIS implementation, a refactored and faster parser and improved condition filtering cost calculations. You can download and run the binaries just like before, but if you want to build it from source, there are some details you should know. Otherwise you may fail to build MySQL (bug #72172).

This labs release requires Boost to build. Specifically, it requires Boost 1.55. But don’t go running off to boost.org looking for the latest tarball just yet — there’s no need for that. The MySQL build system will do everything …

In my previous post I’ve showed some new MySQL 5.6 features which can be very helpful when creating geo-enabled applications. In this post I will show how we can obtain open-source GIS data, convert it to MySQL and use it in our GEO-enabled applications. I will also present at the upcoming Percona Live conference on this topic.

Data sources (US)

For the U.S. we may look at 2 major data sources:

1. ZIP codes with latitude, longitude and zip code boundaries (polygon). This can be downloaded from the U.S. Census website: …