The comments I made have to do with how often you need to do this operation. If it is a one-time thing, manually import the spreadsheet to a staging table (or temporary table if you prefer that title), then write a query to do the transfer of what you wanted, then delete the temp table. Then close the DB, copy it (for safety), then compact and repair the database. If that works, you are done and can delete the copy or call it a "backup" file or something.
BUT... if you have to do this on a repeated basis, that kind of handling can be a problem, particularly if you eventually intend to share this database with others. In the case where this import process needs to be repeated even just a few times, you would not want to "drag around" all of the spreadsheet (even as an externally linked table) if you were not going to be using it. So in this case, the idea would be to decide when you need to do this whole process. You set up a form or macro to drive it.
Inside this process, you would link to the external spreadsheet as thought it were a table. Note that this is actually safe with regard to the spreadsheet since Access will not let you update a spreadsheet linked as a table. So now you have this linkage. Write an INSERT INTO style of query that takes data from the linked spreadsheet and adds it to your table. (Presumably, if you were doing this on a regular basis, this destination table has already been created.) OK, run the action query. But now, you have this linked table dangling off your database that nobody else needs. And YOU don't need it any more once the import is complete, so you unlink it.
Doing it this way, there IS no immediate need for a compact & repair since no temporary table was created then erased and no table was deleted. These latter actions are the most common sources of database bloat that would eventually lead to the need for a compact & repair operation. Remember, the more you have to diddle with the database manually, the more chances you have to make an error and break something, even when doing something so simple as a compact & repair.
The other possibility, using a 3rd database file, is to make an empty database that is set up like you need it with empty tables - defined but no data in them. When the time comes, you COPY that database to a convenient location, link to the tables, do the import INTO THESE TEMP TABLES. Now run your query to extract what you wanted. Then unlink the tables from that copy of the 3rd file. And DELETE THE FILE. Now the fact that it got bloated is immaterial because you cleaned up the bloat in one operation!
Either of the two approaches I mentioned would work to eliminate database bloat making your primary database files slower and uglier. Bulk deletes and structural deletions almost always make a database file ugly and in frequent need of compact & repair operations, which as noted earlier, are to be avoided.