data.table Cheat Sheet
A data.table reference for fast R filtering, calculation, grouping, joins, keys, indexes and reference updates.
What this reference covers
The data.table reference is organized around the i, j and by expression. It connects row filtering, column selection, calculation, grouping, keys, indexes, joins, sorting and reference updates into a practical workflow for R tables that need repeatable and efficient operations.
Read i, j and by as a table contract
Treat i as the row condition, j as the selected or computed columns and by as the grouping definition. Test each part on a small table before combining them. This makes it easier to distinguish a wrong condition from a wrong aggregation or a missing group.
Keep mutation and joins explicit
The := operator can update an object by reference, which is useful for large tables but requires a deliberate copy boundary. Before joining, check key names, types, uniqueness and the expected one-to-one or one-to-many relationship. Compare row counts and unmatched records after the operation.
Maintenance note
Keys, sorting and indexes are performance tools, not a substitute for a data contract. Preserve source data when needed, record derived columns and validate memory-sensitive steps. Content review date: 2026-08-23.
Save to your cloud drive
Save the complete collection first so files remain together and are easier to access across devices.
Quark Cloud Drive
RecommendedSave data.table Cheat Sheet to this cloud drive
Baidu Netdisk
Save data.table Cheat Sheet to this cloud drive
data.table study guide
Learn the i, j and by positions first, then add reference updates, keys and joins while recording row counts, types and copy boundaries.
Before you start
- Prepare a PDF reader and a small data.table for repeatable experiments.
- Understand data frames, column selection, row filtering and grouped summaries in R.
- Record the input row count and key columns before each mutation or join.
Quick start
- 01
Separate i, j and by
Use i for rows, j for columns or calculations and by for groups, verifying each position on a small sample before composing expressions.
- 02
Plan reference updates
Copy the working table when the source must remain unchanged, and check the new column type, units and missing-value rule after using `:=`.
- 03
Check join relationships
Confirm join field names, types, uniqueness and expected cardinality before joining, then compare row counts and unmatched records.
- 04
Review memory and results
Inspect key metrics, object state and derived columns after large operations, and preserve intermediate output when the step is hard to reproduce.
Usage tips
- Use meaningful names for intermediate tables so each transformation remains traceable.
- Validate joins and updates on a small sample before running them on a large table.
- Treat keys, sorting and indexes as performance choices and document their effect on later steps.
Troubleshooting and uninstall
Why did `:=` change my original table?
Reference updates may mutate the object directly. Copy the working table before the update or keep mutation in a clearly named processing stage.
Why did a join produce too many rows?
Check duplicate keys, field types and join conditions on both sides, then aggregate or explicitly model a many-to-many relationship.
Frequently asked questions
What is the central data.table idea?
The central structure is i, j and by for row filtering, column selection or calculation, and grouping, followed by keys and joins as needed.
Why is data.table useful for large tables?
Compact expressions, grouped computation, indexes and reference updates can reduce unnecessary intermediate objects, although the result depends on the data and operation.
What should be checked before using `:=`?
Decide whether the source object may change, copy it when necessary, and verify column types, units and missing values after the update.
What should be checked after a join?
Compare row counts, unmatched records, duplicate keys, field types and important values with the expected relationship.