You are correct; I chose my words poorly. MySQL does not have true materialized views. They have statement-rewriting views and temporary-table views. I was referring to the latter, where the view IS materialized into a concrete table, but then thrown away at the conclusion of the statement. So while it is materialized, it's not persistent, which is the whole point of true materialized views. True materialized views have to be manually created/managed by application code (which is pretty straightforward).

The error is the statement "Materialized views are views that, as you might guess, are materialized when they're needed."

From http://en.wikipedia.org/wiki/Materialized_view : "A materialized view takes a different approach in which the query result is cached as a concrete table that may be updated from the original base tables from time to time. This enables much more efficient access, at the cost of some data being potentially out-of-date. It is most useful in data warehousing scenarios, where frequent queries of the actual base tables can be extremely expensive."

From http://dev.mysql.com/doc/refman/5.1/en/faqs-views.html :
"23.6.5: Does MySQL 5.1 have materialized views?

No. "

(Same answer for MySQL 5.0, 5.1, and 6.0)

MySQL does not allow parameter values (aka user variables) with views, but there is a workaround using a stored function (which can access and then return the user variable). But the performance is terrible.

Previously I have used sub-queries (in MySQL 4.1), though not with user variables, and they have always been impressively fast (but I had to write my own VBA code to nest sub-query definitions into higher-level queries). Views should be neater but with their inability to access user variables (except inefficiently as it seems through a stored function), and the performance hit you describe, I guess I must stick to coded sub-queries for now.

I'm pretty sure that the issue in my case was that the view engine was rematerializing the view over and over again within the same query. If it had just materialized it once and reused it, it would have been fine, even without an index. But still a good thought to keep in mind.

Sadly, the row count is tiny: less than a thousand rows.

I didn't do exceptionally granular testing, but the main offenders were aggregating subqueries. It would be possible to duplicate the subqueries in the "view" throughout the queries that leverage the view to get most of the performance benefit, but the maintenance downside was significat. That's actually the path I went down first, because I didn't want to jack up my database, but it wasn't worth it. The app is very SELECT-centric with relatively few updates, so manually managing the "view" tables isn't actually much of a headache.

There is a feed link at the bottom for subscribing to comments. I'd also naively assumed that WordPress would email thread participants when new comments were posted (like MovableType did), but I just looked it up, and that doesn't seem to be the case. I found a plugin that will provide that functionality; I'll be installing it in just a sec.

Also just out of curiosity how much data is this working with, thousands, tens of thousands of rows, more? Does this size matter, like the larger it is, the more you can save?

P.S. I wish your blog had a comment email subscription option.

Yeah, it's absolutely denormalization.

When MySQL does it, it's an implementation detail of the server; if they changed to something else the DB client wouldn't care. As such, it's not a denormalization you'd care about.

When I do it manually, it's a much bigger deal. I'd love to have just changed my view to be of the "rewritten/merged" style, but with the current MySQL implementation, that's impossible. With the database not able to directly address my problem, it's up to me to choose between performance and maintenance overhead.

For the cost of having to rebuild my "view" tables when data is updated and the potential to have slightly outdated statistics in the "views", I can drop a significant number of queries from the 10-15 second range down to 40-100 milliseconds. Often there are multiple instance per page request as well. So the tradeoff seems a no-brainer to me.

I should also have mentioned that this is a CPU-bound limitation. On my laptop (slower disks, faster CPU, equivalent free RAM), the queries with the views run around a second a piece, compared with 10-15 seconds on the server.