http://kathyravan.blogspot.com/2008/12/blackhole-mysql-storage-engine.html

This is indeed good idea and a bit different approach – instead of using different set of tables you patch application a bit so it can use same “table” for multiple users at the same time.

and indeed such views can be used for Inserts unless you do not have columns specified.

what about using session variables to achive the effect with inserts and reduce the number of views?

At the start of the script you do:

[CODE]SET @owner_id = 12345[/CODE]

Then use a BEFORE INSERT trigger for the shared table (owner_id field should be in the view as well):

[CODE]CREATE TRIGGER post_insert BEFORE INSERT ON posts AS
FOR EACH ROW BEGIN
NEW.owner_id = COALESCE(NEW.owner_id, @owner_id);
END;[/CODE]

Also, you don’t even need an own set of views for each user. You just need a one set of views. Think of doing:

[CODE]CREATE VIEW owner_posts AS
SELECT * FROM posts
WHERE owner_id = @owner_id;[/CODE]

But, yes, variables can’t be used inside a view definition. I have [URL=http://omelnyk.net/blog/2007/06/18/using-views-with-variables-in-mysql/]outlined[/URL] a simple workaround for that. Basically, create a function:

[CODE]CREATE FUNCTION owner_id
RETURNS INTEGER AS
RETURN @owner_id;[/CODE]

That way, you get two benefits:

- Most of INSERTs inside an application can remain unchanged. INSERTS that have to be changed are INSERTs without explicitly specified field list. But it is not the case, except for maybe several exceptions, for the applications you have mentioned above, as they have been designed to allow possible table structure extensions;
- You don’t have to use a huge set of views, one set of views for all users would work just fine;

If it is create the test case and submit bug to MySQL
I expect it is something different.

I did access all views created in my test.

There was a ratio of 100 views per innodb table. The system _used_ to be 40,000+ innodb and/or myisam tables, which then changed to 80,000+ views then a few hundred innodb tables. The views used 600 megabytes over that bit.

It would bloat as the views were first accessed, then the memory never went down. Temp tables/files?

Also I just checked by creating 500.000 views – and using all of them – there does not seems to be any memory hog related to that.

May be besides views you had Innodb tables ? These consume memory if created in numbers.

A developer tried this one a development machine I managed a few months ago. We ended up with over 80,000 views in a single instance and MySQL was not exactly happy. It soaked an extra 600 megabytes without having them in use, and querying the INFORMATION_SCHEMA at all became uselessly slow. The DB was not under high query load, but each developer had an “instance” of several thousand views emulating production, with sometimes several instances.

If I had more time I’d test these methods, wondering if they hammer MySQL less hard?

For simple views like this indexes will be used just fine because simply where clause will be appended to all the queries you run on this view using “merge” algorithm.

Indeed I did not note about indexes – if you go with such solution you also redo indexes on the base table to include user_id as a prefix as it is now always specified in your queries.

WordPress is good example. basically any forum applications – PHPBB etc, if you’re to run isolated installations.