SlimStat Database Tables and Columns Reference

SlimStat creates four tables in your WordPress database: slim_stats for pageviews, slim_events for outbound clicks and other events, and an archive counterpart for each. Every name carries your site’s table prefix, so a default install writes pageviews to wp_slim_stats. Deleting the plugin removes none of it unless you opt in first.

The four tables and the prefix rule

Table names resolve through $wpdb->prefix, which is whatever $table_prefix in wp-config.php sets rather than a literal wp_. On multisite every subsite owns its own set of four, so blog 2 writes to wp_2_slim_stats. Never hardcode wp_ in a query.

All four are created COLLATE utf8_general_ci, and with ENGINE=InnoDB where the server reports InnoDB as available. SlimStat Pro adds no tables of its own; its external-database add-on relocates these same four rather than creating more.

The table layout is not part of the plugin’s public API and does change between major versions. This page describes the version currently published on wordpress.org. Run SHOW CREATE TABLE wp_slim_stats on your own install before writing anything that depends on a column’s exact type.

Every column in wp_slim_stats

Reading these from PHP is covered in the database API methods and retrieving and outputting data in PHP.

Indexes, and the four that are optional

Two indexes on slim_stats are always present besides the primary key: slim_stats_dt_idx on dt, and the composite stats_dt_visit_idx on dt and visit_id. Anything filtering on a date range is therefore already served.

Four more are prefix indexes over long text columns, and they are controlled by Increase Performance (db_indexes) at Settings, Maintenance. The plugin’s own help text puts their cost at roughly 30% extra table size.

Each name carries the table prefix, so on a default install the first is wp_slim_stats_dt_idx. A query filtering on a long text column without one of the optional indexes will scan.

The events table

slim_events has seven columns: event_id, type, event_description, notes, position, id and dt. position stores the click coordinates the heatmap report renders, which is a Pro feature — see how to enable and view the heatmap.

The id column is a real foreign key onto slim_stats(id), declared ON UPDATE CASCADE ON DELETE CASCADE, so deleting a pageview deletes its events with it and you never clean up orphans by hand. slim_events_archive carries the same seven columns without the foreign key, because the pageviews it refers to have moved to the archive table.

Querying from your own code

Read through $wpdb rather than opening your own connection, so an install pointing SlimStat at an external database keeps working:

global $wpdb;
$table = $wpdb->prefix . 'slim_stats';

$top = $wpdb->get_results( $wpdb->prepare(
    "SELECT resource, COUNT(*) AS hits
     FROM {$table}
     WHERE dt > %d
     GROUP BY resource
     ORDER BY hits DESC
     LIMIT 10",
    strtotime( '-30 days' )
) );

The slimstat_get_results_sql and slimstat_get_var_sql filters let you modify the queries SlimStat itself runs, and slimstat_custom_wpdb lets you substitute the connection.

What an uninstall removes

Deleting the plugin removes nothing by default. uninstall.php reads the delete_data_on_uninstall setting and returns immediately unless it is on, so stats, settings and tables all survive a delete-and-reinstall. Deactivating never runs the uninstaller at all.

With the toggle on, uninstall also deletes slimstat_visit_id, slimstat_filters, slimstat_tracker_error, the goals and funnels records and their cached transients. On a multisite network it repeats the whole sequence for every non-deleted, non-spam site. Where a Pro external database is configured, it connects to that database to drop the tables there too.

To reclaim space without removing the plugin, use the retention window rather than a manual DROP — retention and auto-purge covers what each setting does to old rows and which of them archives rather than deletes.