Specifically, this is designed for PHP & MySQL, but in theory could be adapted to work with other platforms.

The idea is to take the large part of the data (the content) and place it into a set of tables where it can be managed by a resource system.

Suppose we have a table called ‘posts’, which stored a unique ID, title, date and content for each row. Now suppose we used this table to store the daily posts from our members. If we had 1000 members who posted daily, it wouldn’t be long before our table reached a phenomenal size.

When you query that table for a list of the entries, you’ll almost never use the content field. Separating the content from the rest of the information allows for quicker alteration of what we’ll refer to now as the ‘log’.

This calls for a system that can manage content in its bare form – text. We need to be able to take the content, submit it to a function that returns a resource-ID that we can store in the ‘log’. Then later retrieve that data using the resource-ID.

Making the system structured like this will allow for further optimisation later using a utility called MEMCACHED, but we’ll leave that for a later post.

There are many advantages to this system, that we’ll discuss in the next post.

So here’s a few (unorganised) tips that I think will help:

1. Don’t make a VARCHAR field 255 characters if it’ll only ever be 32 characters long.
    
2. Use UNSIGNED where possible (that’s anywhere you’re not going to store a negative value).
    
3. Use the smallest field types possible, if your range doesn’t exceed 0~255 then TINYINT is your best friend. Applying these basic tactics to all fields will help reduce the size of your table and ultimately reduce the overall workload that MySQL has to deal with.
    
4. Split large data into other tables. If you have a LONGTEXT in your table, you’ll find that disk fragmentation causes hefty disk work. To help prevent this you can move the LONGTEXT fields into a table on their own. We’ll call the first table the ‘log’, and the second table the ‘data’. You store all the basic information in the ‘log’ table (such as the title, date and size), and then the content in the ‘data’ table.
    

5. In addition to point 4- if you have way too much data, try making multiple ‘data’ tables fed by the same ‘log’ table, this makes optimization much easier.
    
6. If you’re using PHP or something similar, you can usually use sessions to store data that is frequently used rather than requesting it from the database.
    
7. In addition to point 6 – if you have many members accessing the same data, sessions just won’t cut it. But installing and using MEMCACHED might – it gives you a read/write cache by using some of your spare computer memory.
    
8. Always make sure you make use of your indexes properly.
    
9. Never allow indexes that aren’t used to remain active.