You have to decide what this data is, and how mobile users will access it, and if they have to or want to, or what.
If you have very wide and dense tables, you may want to just keep them on the page as they are and let users scroll those suckers sideways... in which case, floating/sticky column/row headers would be nice.
People are willing to scroll, even sideways, if they see a reason for it and they want that content. A table can be a good example of that... but it depends on the table data.
If it's a two-column table, then possibly your markup wouldn't have to be a table at all-- a definition list (keys and values) can convey the same information and are easier to deal with using media queries.
If your table is kinda in the middle in size, and very static, you could try a modified version of Chris Coyier's responsive data tables. Due to the brittleness of this technique, I see it as a sort of last resort.
Either way, it would be good to look around for a way to offer the data in a non-table style: paragraphs or bullet lists of key points, if possible.
I used Chris' method when making insurance bonus/malus tables because I couldn't see another way to transmit the info, plus there was a PDF people could download for later or something.
What peterorl is talking about is, having several smaller-for-mobile tables in the markup, but hidden from Desktop users using the css media queries-- no JS necessary. So if the user is on a mobile, you simply let the many-smaller-tables present themselves, and hide the large table (or, if you're building mobile-first, you could have only the smaller tables and use JS or something to assemble or ajax-add the larger table if the screen is larger-than-mouse-turd-size. Desktoppers/large screen users without JS or with crappy internets could still get the info from the less-glamourous smaller tables.
If the tables are things where people would only be looking up a single value from a large table, consider offering a search, like with an actual form and stuff. You could have your JS or your backend read the table and send back the data linked to the search term, presented in any non-table manner. Examples would be a table where various things like prices of plans are listed, or data going by age or location, where people tend to want to only look up the relevant row/column.