[mythtv-users] anyone using percona instead of mysql (stock)?
Michael T. Dean
mtdean at thirdcontact.com
Tue Dec 20 20:52:59 UTC 2011
On 12/20/2011 09:46 AM, Jay Ashworth wrote:
> From: "Gary Buhrmaster"
>> I too have been running innodb for years at this point, and
>> my recollection was that the 'select count(*)' on innodb
>> resulted in a table scan (and an index lookup on myisam?),
>> and that mythtv used that construct in numerous queries.
> Well, SELECT COUNT(1) generally works fine, and doesn't touch the data at all,
> in my experience.
The issue to which Gary was referring is the fact that MyISAM data
format stores the exact row count in the binary data file; whereas
InnoDB stores no such value. Therefore, a COUNT(*) (or COUNT(1)) on an
InnoDB table requires reading the table (and appropriate locking,
etc.--due to the differences in multi-transaction usage between MyISAM
and InnoDB); whereas on a MyISAM table it's basically just returned
without any data access. Note, also, that COUNT(column) has a different
effect from COUNT(*)--it returns the count of rows with non-NULL
values--which means it is most likely not a valid replacement.
http://dev.mysql.com/doc/refman/5.0/en/group-by-functions.html#function_count
And, once again, I'd just like to reiterate the fact that we only
support databases using MyISAM storage for all tables, with the
exception of MythWeather tables (which are InnoDB). Unless you are an
aspiring database admin--or you already are a database admin, and feel
that you don't get to do enough of the things you do at work when you're
at home--your best bet is to use a supported (unmodified) database
schema and trust that we'll convert the storage engine when
appropriate. And, even if you want to do database administration at
home, unless you want to spend a lot of time reading MythTV code and
trying to diagnose and work around issues that arise when modifying the
schema for which MythTV code is designed, your best bet is to use the
unmodified schema. And, unless you know of MySQL performance problems
with MythTV, there's no reason to worry about improving MySQL
performance with MythTV. :)
Mike
More information about the mythtv-users
mailing list