Always ensure you are optimizing to the primary use case and ensure your flow supports the side cases.
Is the primary interaction that users will want to always export all table rows and not the viewable table rows? If so, you can have Export the entire table and not need selection. I have a use case like this which I did this design for now. The only thing the export picks up is if any filters have been set up and the UI will only export the total rows returned based on the set of filters, but it doesn't take into account what's viewable. This interaction is optimized to the use case I am working with and users' expectations.
If the primary use case is that users will want to first select which rows want to export, you can handle it as you have proposed which will work but you may want a way for the user to select how many results would want to display if there rae typical expected ranges.
Example:
Display [1-10] [1-50] [1-100] [1-200] [All]
I would definitely recommend to first research how your users are really using the application now based on its limitations and optimize to the majority use case and usage.