I agree with TheoPeterson's points, and I will add on to warn that there are more important things than speed:
MySQL (or other relational databases) usually hold up better when you start increasing the number of records in your tables. Flat files with 1000s of records starts to become very very slow. MySQL can hold up quite well even when you get into 5 digits+. (There have been projects where I've used text files thinking that there'd only be a couple hundred records. Several years later, let's just say that the client exceeded my expectations.)
- MySQL is a lot easier to work with when your tables need to mutate. If your client decides that they want to add/drop fields, then it's easier to do using a few ALTER statements, rather than hacking scripts together to manually rearrange your database tables. It's better during the development process as well.
With flat files you have to be a lot more careful about file locking and data integrity. That's not as much of a concern with most RDBMs.
With flat files you have to be a lot more careful about security. With MySQL, etc., you have a lot of flexibility, and can assign access privledges to each action (SELECT,INSERT,DELETE,etc.).
...and so on. I know that you weren't using your benchmarks to start a war about MySQL vs flat files, but you did mention that you were looking for the "best way". In my humble opinion, the fastest way isn't the best way in this case. For a lot of projects, messing with flat files or CSVs are just too much of a headache.
It is good to see the benchmarks though. Thanks for taking the initiative!